IOAuthAuthorizationServerProvider Interface

Called at the final stage of an incoming Authorize endpoint request before the execution continues on to the web application component responsible for producing the html response. Anything present in the OWIN pipeline following the Authorization Server may produce the response for the Authorize page. If running on IIS any ASP.NET technology running on the server may produce the response for the Authorize page. If the web application wishes to produce the response directly in the AuthorizeEndpoint call it may write to the context.Response directly and should call context.RequestCompleted to stop other handlers from executing. If the web application wishes to grant the authorization directly in the AuthorizeEndpoint call it cay call context.OwinContext.Authentication.SignIn with the appropriate ClaimsIdentity and should call context.RequestCompleted to stop other handlers from executing.

Called when a request to the Token endpoint arrives with a "grant_type" of "client_credentials". This occurs when a registered client application wishes to acquire an "access_token" to interact with protected resources on it's own behalf, rather than on behalf of an authenticated user. If the web application supports the client credentials it may assume the context.ClientId has been validated by the ValidateClientAuthentication call. To issue an access token the context.Validated must be called with a new ticket containing the claims about the client application which should be associated with the access token. The application should take appropriate measures to ensure that the endpoint isn’t abused by malicious callers. The default behavior is to reject this grant type. See also http://tools.ietf.org/html/rfc6749#section-4.4.2

Called when a request to the Token endpoint arrives with a "grant_type" of "refresh_token". This occurs if your application has issued a "refresh_token" along with the "access_token", and the client is attempting to use the "refresh_token" to acquire a new "access_token", and possibly a new "refresh_token". To issue a refresh token the an Options.RefreshTokenProvider must be assigned to create the value which is returned. The claims and properties associated with the refresh token are present in the context.Ticket. The application must call context.Validated to instruct the Authorization Server middleware to issue an access token based on those claims and properties. The call to context.Validated may be given a different AuthenticationTicket or ClaimsIdentity in order to control which information flows from the refresh token to the access token. The default behavior when using the OAuthAuthorizationServerProvider is to flow information from the refresh token to the access token unmodified. See also http://tools.ietf.org/html/rfc6749#section-6

Called to determine if an incoming request is treated as an Authorize or Token endpoint. If Options.AuthorizeEndpointPath or Options.TokenEndpointPath are assigned values, then handling this event is optional and context.IsAuthorizeEndpoint and context.IsTokenEndpoint will already be true if the request path matches.

Called before the TokenEndpoint redirects its response to the caller.

Called to validate that the origin of the request is a registered "client_id", and that the correct credentials for that client are present on the request. If the web application accepts Basic authentication credentials, context.TryGetBasicCredentials(out clientId, out clientSecret) may be called to acquire those values if present in the request header. If the web application accepts "client_id" and "client_secret" as form encoded POST parameters, context.TryGetFormCredentials(out clientId, out clientSecret) may be called to acquire those values if present in the request body. If context.Validated is not called the request will not proceed further.

Called for each request to the Token endpoint to determine if the request is valid and should continue. The default behavior when using the OAuthAuthorizationServerProvider is to assume well-formed requests, with validated client credentials, should continue processing. An application may add any additional constraints.