Best practices in Identifying the Authorization Context of an OAuth2 Token
In this post, we’ll discuss the best practices of identifying the authorized user of an access token and what approach we recommend in doing so.
WSO2 Identity Server supports OAuth2 and OpenID Connect frameworks that define standard protocols on authorizing third-party applications when accessing user identities such that access to unauthorized content is restricted.
Within this framework, any third application or a resource server should use a valid token to retrieve user attributes from the authorization server. According to the specification, the user should have given consent for these applications beforehand. The spec suggests the following two approaches on how an application should request user information after a valid access token is acquired from the authorization server.
id-token
Here user needs to authenticate and authorize the application to access his claims. And claims will be sent in the id-token in JWT format, based on the consent given during the authentication process.
user-info endpoint
An application can invoke the user-info endpoint with a valid access token requesting for a set of claims of the user who authorized the token. This token should contain the required scope to access the user claims. The authorization server will consider the token scope, user’s consent and then issue the claim set.
In both of the above methods, the application/resource server gets access to the user’s claims(resources) because the user(resource owner) has provided consent to do or the respective application has the authorization to invoke it.
In addition to spec-compliant approaches, we also provide the capability to retrieve authorized user information via the following approaches.
Token Validation SOAP Service
This was our legacy approach before we had the implementation of user-info endpoint or id-token.
Introspection Endpoint
Here an application authenticates and can retrieve any claim.
Above two options are disabled in the product out of the box. Anyone who needs to enable it should enable the following global config in <IS_HOME>/repository/conf/identity/identity.xml file.
<AuthorizationContextTokenGeneration><Enabled>true</Enabled> <TokenGeneratorImplClass>org.wso2.carbon.identity.oauth2.authcontext.JWTTokenGenerator</TokenGeneratorImplClass> <ClaimsRetrieverImplClass>org.wso2.carbon.identity.oauth2.authcontext.DefaultClaimsRetriever</ClaimsRetrieverImplClass><ConsumerDialectURI>http://wso2.org/claims</ConsumerDialectURI><SignatureAlgorithm>SHA256withRSA</SignatureAlgorithm><AuthorizationContextTTL>15</AuthorizationContextTTL></AuthorizationContextTokenGeneration>
Why we have disabled it in the product is due to the severe security implications it imposes on WSO2 when it is acting as the authorization server. We do not recommend enabling it as well. I will explain these implications in detail below.
Self-Contained Access Token
This is another way, how an application can obtain user information from token endpoint in the form of a JWT instead of an opaque token. In a self-contained-type, information associated with an access token is embedded in the access token itself in addition to user claims.
Why retrieving user-claims via TokenValidationService/Introspection is NOT recommended?
Introspection endpoint and TokenValidationService can be called by any party who has the authorization to invoke it. But that doesn’t mean they have the authorization to view the particular user’s claims. They are only authorized to see the metadata of the access token.
Therefore if we enable user-claim retrieval via these options, it allows the resource server and any other third-party application who is in possession of a valid access token, to get any claim of the user and there is no restriction. The respective application may not be authorized to do so.
What about self-contained access token?
Here we have a plus point when compared to other two. It is that an application can retrieve user information only after the user successfully authenticates and provides consent to retrieve his claims. However since the token is self-contained and can be verified without invoking the authorization server, there is no way to invalidate the token in case it gets counterfeited, until the token expires.
Due to the above-mentioned implications of these non-standard alternative approaches, we are recommending only the OIDC spec-compliant approaches to retrieve authorized user information of an access token. That is either via the id-token or user-info endpoint.
Thanks for reading!
