please consider returning more descriptive errors like `ErrInvalidRequest`

[arvenil]

https://tools.ietf.org/html/rfc6749 defines error responses returned to clients, however this library seems to completely shadow received responses so one can't distinguish between different type of errors.

For example for Resource Owner Password Credentials Grant (https://tools.ietf.org/html/rfc6749#section-4.3) RFC6749 defines error message and codes in https://tools.ietf.org/html/rfc6749#section-5.2 Now we can't distinguish between e.g. invalid_request and invalid_grant as what the func PasswordCredentialsToken returns is basic error message

oauth2/internal/token.go

Lines 174 to 176 in 2cd4472

	if code := r.StatusCode; code < 200 || code > 299 {
	return nil, fmt.Errorf("oauth2: cannot fetch token: %v\nResponse: %s", r.Status, body)
	}

Well, since there is response in the error message I could parse it but I think you realize ugliness of such a hack ;)

What I would expect here is following standard concepts from golang standard library and to introduce package errors, and export them. So instead returning meaningless errors (something went wrong but what?) we could receive something more useful like ErrInvalidRequest or ErrInvalidGrant.

Right now my biggest real life issue is that I can't distinguish that user provided wrong credentials from any other unknown error.

[adayoung]

YES! This! Please!! 😍
@arvenil How are you actually doing it at the moment while it's not there?

[arvenil]

@adayoung Like I stated in description the only method is to parse whole message for e.g. invalid_request or invalid_grant - ugly hack but "works".

[adayoung]

@arvenil Oh me too! I ended up writing this. It probably doesn't cover everything but so far it catches things I'm likely to encounter. I'll have to keep a lookout for when it doesn't! I'd really appreciate if you'd point to some code examples of how you're doing it. I'm just learning Go and I may not be doing things right at all 😊