-
Notifications
You must be signed in to change notification settings - Fork 0
12 OAuth
The application that is attempting to get access to the user's account. It needs to get permission from the user before it can do so.
The API server used to access the user's information.
Server that presents the interface where the user approves or denies the request. In smaller implementations, this may be the same server as the API server, but larger scale deployments will often build this as a separate component.
The person who is giving access to some portion of their account.
Before you can begin the OAuth process, must first register a new app with the service. Usually register basic information such as:
- application name
- website
- a logo
- etc
- redirect URI
The service will only redirect users to a registered URI. Any HTTP redirect URIs must be protected with TLS security; so the service will only redirect to URIs beginning with "https". This prevents tokens from being intercepted during the authorization process. Native apps may register a redirect URI with a custom URL scheme for the application, which may look like demoapp://redirect.
The first step of OAuth 2 is to get authorization from the user. For browser-based or mobile apps, this is usually accomplished by displaying an interface provided by the service to the user.
OAuth 2 provides several "grant types" for different use cases. The grant types defined are:
- Authorization Code for apps running a web server, browser-based and mobile apps.
- Password for logging in with a username and password.
- Client credentials for application access
- Implicit was previously recommended for clients without a secret, but has been superseded by using the Authorization Code grant with no secret.
Web apps are written in a server-side language and run on a server where the source code of the application is anot available to the public. This allows the application to use its client secret when communicating with the authorization server, which can help avoid some attack vectors.
Create a "Log In" link sending the user to:
https://authorization-server.com/auth?response_type=code&client_id=CLIENT_ID&redirect_uri=REDIRECT_URI&scope=photos&state=1234zyx
-
response_type=code: indicates that your server expects to receive an authorization code -
client_id: The client ID you received when you first created the application -
redirect_uri: Indicates the URI to return the user to after authorization is complete -
scope: One or more scope values indicating which parts of the user's account you wish to access -
state: A random string generated by your application, which you'll verify later
The user sees the authorization prompt: if the user clicks "Allow," the service redirects the user back to your site with an auth code
https://example-app.com/cb?code=AUTH_CODE_HERE&state=1234zyx
- Code - the server returns the authorization code in the query string
- State - the server returns the same state value that you passed
Should first compare this state value to ensure it matches the one you started with. Can typically store the state value in a cookie or session, and compare it when the user comes back. Ensures your redirection endpoint isn't able to be tricked into attempting to exchange arbitrary authorization codes.