Extension Points for OAuth

This extension point can be used to implement a grant validator that validates the grant request sent to the '/oauth2/token' endpoint. Request parameters and headers can be validated by implementing this extension point.
If a new grant type is being implemented and defined with a new grant type identifier with the OAuth Grant Handler extension, you must also implement a grant validator and register that against the same grant type identifier from the identity.xml.
If a supported grant type is to be modified you may implement a grant validator if needed, otherwise supported grant type validators can be reused.

org.wso2.carbon.identity.oauth2.token.handlers.clientauth.BasicAuthClientAuthHandler

org.wso2.carbon.identity.oauth2.token.OauthTokenIssuerImpl

org.wso2.carbon.identity.oauth.tokenprocessor.PlainTextPersistenceProcessor

Use this if you want to store access tokens, refresh tokens, authorization codes, and client secrets as plain text values. By default, WSO2 Identity Server hashes access tokens, refresh tokens, authorization codes, and client secrets using two UUIDs and HMAC-SHA1 hash function, which is known to resist the strongest attack known against HMAC. With the default implementation you can use a valid token until it is either revoked or becomes invalid.

This extension point can be used if token validation and scope validation needs to be customized when invoking the token validation endpoint. Token validators can be registered per token type such as 'bearer'.
A default implementation that supports for 'bearer' token type is available.

This extension point can be used to customize the token that can be generated relevant to the authorization context by invoking the token validation endpoint.
By default, a JWT token generation implementation is supported with following properties encoded to each token validation request.

• subscriber, applicationName, apiContext, version, tier, and endUserName
• Additional properties can be encoded by engaging a claims retriever.
• The JWT header and body are base64 encoded separately and concatenated with a dot

Finally the token is signed using SHA256 with RSA algorithm.

This extension point can be used if additional claims or properties needs to be engaged to the JWT token generated in the token validation response as explained in extension point above.
The default implementation reads user claim values from the default Carbon user store.

This is intended to perform access delegation, scope validation and to issue tokens based on token type such as 'code', 'token' etc. Multiple implementations can be registered upon the token type.
This extension can be used if a specific token type needs to be supported or customized.

org.wso2.carbon.identity.oauth2.authz.handlers.CodeResponseTypeHandler
org.wso2.carbon.identity.oauth2.authz.handlers.TokenResponseTypeHandler

This extension point can be used if access token validation, when accessing '/oauth2/userinfo' resource, needs to be changed.
By default, the access token issued is validated against the token validation service and 'scope' request parameter is validated to have 'openid' scope.

This extension point can be used if the user claim set returned when invoking '/oauth2/userinfo' resource needs to be modified.

This extension point can be used if the request validation logic, for requests initiated for '/oauth2/userinfo', needs to be changed. 

The default behavior is validating the schema and authorization header according to the specification.

This extension point can be used if the user info response returned when accessing '/oauth2/userinfo' resource needs to be changed.
Implementations supporting both JSON and JWT response formats are available. By default JSON format supported implementation is configured in the identity.xml

org.wso2.carbon.identity.oauth.endpoint.user.impl.UserInfoJWTResponse