About authorization options for OAuth Apps

Web Application Flow
Non-Web Application Flow
Redirect URLs

Web Application Flow

The flow to authorize users for your app is:

Users are redirected to request their GitHub identity
Users are redirected back to your site by GitHub
Your app accesses the API with the user’s access token

1. Users are redirected to request their GitHub identity

GET https://github.com/login/oauth/authorize

Parameters

Name	Type	Description
`client_id`	`string`	Required. The client ID you received from GitHub when you registered.
`redirect_uri`	`string`	The URL in your application where users will be sent after authorization. See details below about redirect urls.
`scope`	`string`	A space-delimited list of scopes. If not provided, `scope`defaults to an empty list for users that have not authorized any scopes for the application. For users who have authorized scopes for the application, the user won’t be shown the OAuth authorization page with the list of scopes. Instead, this step of the flow will automatically complete with the set of scopes the user has authorized for the application. For example, if a user has already performed the web flow twice and has authorized one token with `user` scope and another token with `repo`scope, a third web flow that does not provide a `scope` will receive a token with `user` and `repo` scope.
`state`	`string`	An unguessable random string. It is used to protect against cross-site request forgery attacks.
`allow_signup`	`string`	Whether or not unauthenticated users will be offered an option to sign up for GitHub during the OAuth flow. The default is `true`. Use `false` in the case that a policy prohibits signups.

2. Users are redirected back to your site by GitHub

If the user accepts your request, GitHub redirects back to your site with a temporary code in a code parameter as well as the state you provided in the previous step in a state parameter. If the states don’t match, the request was created by a third party and the process should be aborted.

Exchange this code for an access token:

POST https://github.com/login/oauth/access_token

Parameters

Name	Type	Description
client_id	string	Required. The client ID you received from GitHub for your GitHub App.
client_secret	string	Required. The client secret you received from GitHub for your GitHub App.
code	string	Required. The code you received as a response to Step 1.
redirect_uri	string	The URL in your application where users are sent after authorization.
state	string	The unguessable random string you provided in Step 1.

Response

By default, the response takes the following form:

access_token=e72e16c7e42f292c6912e7710c838347ae178b4a&token_type=bearer

You can also receive the content in different formats depending on the Accept header:

Accept: application/json
{"access_token":"e72e16c7e42f292c6912e7710c838347ae178b4a", "scope":"repo,gist", "token_type":"bearer"}

Accept: application/xml
<OAuth>
  <token_type>bearer</token_type>
  <scope>repo,gist</scope>
  <access_token>e72e16c7e42f292c6912e7710c838347ae178b4a</access_token>
</OAuth>

3. Use the access token to access the API

The access token allows you to make requests to the API on a behalf of a user.

GET https://api.github.com/user?access_token=…

You can pass the token in the query params as shown above, but a cleaner approach is to include it in the Authorization header.

Authorization: token OAUTH-TOKEN

For example, in curl you can set the Authorization header like this:

curl -H "Authorization: token OAUTH-TOKEN" https://api.github.com/user

Non-Web Application Flow

Use Basic Authentication to create an OAuth2 token using the interface. With this technique, a username and password doesn’t need to be permanently stored and the user can revoke access at any time.

Note: When using the non-web application flow to create an OAuth2 token, make sure to understand how to work with two-factor authentication if you or your users have two-factor authentication enabled.

Redirect URLs

The redirect_uri parameter is optional. If left out, GitHub will redirect users to the callback URL configured in the OAuth Application settings. If provided, the redirect URL’s host and port must exactly match the callback URL. The redirect URL’s path must reference a subdirectory of the callback URL.

CALLBACK: http://example.com/path

GOOD: http://example.com/path
GOOD: http://example.com/path/subdir/other
BAD:  http://example.com/bar
BAD:  http://example.com/
BAD:  http://example.com:8080/path
BAD:  http://oauth.example.com:8080/path
BAD:  http://example.org