-
Notifications
You must be signed in to change notification settings - Fork 1
Supported Auth Flow Overviews
If you've already obtain a token and/or you want to handle the actual authorisation flow yourself, you can. Assuming you've done the work to obtain a token already, configure your client like this;
This is the primary auth flow supported by this library. It is mainly suited for system to system communications where there is no user present. The client presents credentials to the server and receives a token, the token is then used to authorise requests. The token may expire, and a refresh token (if provided by the server) can be used to renew the token.
To use the client credentials flow, configure your client like this;
This is the normal authorisation flow used with OAuth 2.0 when a user is present, common in mobile apps and websites. While the library provides support for this flow, the requirement to have the user enter credentials during the flow makes it awkward in many scenarios. It may be better to handle the actual auth flow outside of the library code, then just use library components to sign requests with the token, and refresh it if possible.
To use the client authorization flow, configure your client like this; NB: You'd probably want to use WebAuthenticationBroken (if it's available on your platform) to prompt the user to authorise the token request. Otherwise, you'd like use a TaskCompletionSource with your own dialog.
Some 3rd parties have implemented OAuth 2.0 in a way that does not appear to be officially part of the OAuth specification. The authorization_code grant type is still used and the general flow is similar. The main difference is that instead of redirecting the user agent (browser) to a web page for the user to log in, the credentials are posted to the authorisation end point and the server returns a token. This makes it a bastardised combination of the Client Credentials and Authorization Code flows.
To use the client credentials flow, configure your client like this;