This post is the fifth part of a series of blog posts entitled Creating your own OpenID Connect server with ASOS:
- Introduction
- Choosing the right flow(s)
- Registering the middleware in the ASP.NET Core pipeline
- Creating your own authorization provider
- Implementing the resource owner password credentials grant
- Implementing the authorization code and implicit flows
- Adding custom claims and granting scopes
- Testing your authorization server with Postman
- Conclusion
Implementing the resource owner password credentials grant (abbreviated ROPC
for brevity) is quite easy with ASOS as the only thing you have to do is to provide your own implementation of ValidateTokenRequest
and HandleTokenRequest
.
But to properly implement these events, you first need to determine what's the best client authentication policy for your application.
Implementing ValidateTokenRequest
to validate the grant type and the client application credentials
When implementing flows using backchannel communication (i.e resource owner password credentials grant, client credentials grant, authorization code flow or refresh token grant), the ValidateTokenRequest
event must be overridden to validate the token request.
So, what are you supposed to validate in this event? Mainly two things:
- The grant type: in most cases, you'll likely want to restrict the grants a client application is allowed to use (e.g resource owner password credentials only):
ValidateTokenRequest
is the best place for that.
It should be noted that ASOS doesn't validate the grant_type
value, that can even contain a custom value for extension grants: if you only want to support standard grants, it's up to you to reject the token request by calling context.Reject()
.
IsAuthorizationCodeGrantType()
, IsRefreshTokenGrantType()
, IsPasswordGrantType()
and IsClientCredentialsGrantType()
can be used for this exact purpose.
- The client credentials (
client_id
/client_secret
): the OAuth2 specification explicitly states that confidential applications (i.e applications that are able to keep their credentials secret, like server-side apps) must authenticate when using the token endpoint. This security measure is extremely important as it's the only way to prevent malicious applications from retrieving an access token on behalf of a legitimate confidential application.
Contrary to popular belief, client authentication is never mandatory when using the token endpoint (except for the client credentials grant), which means that public applications like JS or mobile apps are allowed to use the resource owner password grant without having to send their credentials.
In practice, it's up to you to decide whether your token endpoint should accept unauthenticated requests or not, depending on the type of client you'll use.