This is a description of the OAuth2 flow from 3rd party web sites.

In the Web Application flow (also known as the Authorization Code flow), the resource owner (a 42 user) is first redirected by the application to the OAuth authorization server at the API provider. The authorization server checks to see if the user has an active session (in our case, if the user is logged on the 42 intranet). If she does, the authorization server prompts her for access to the requested data. After she grants access, she is redirected back to the web application and an authorization code is included in the URL as the code query parameter: http://www.example.com/oauth_callback?code=ABC1234

Because the code is passed as a query parameter, the web browser sends it along to the web server that is acting as the OAuth client. This authorization code is then exchanged for an access token using a server-to-server call from the application to the authorization server. This access token is used by the client to make API calls.

Let's see how we can implement it with the 42 API.

Redirect users to request 42 access

That's the first step. Link or redirect users to the API authorize url: https://api.intra.42.fr/oauth/authorize. This must be properly formatted for your application and will return a permissions screen for the user to authorize. For convenience, a formatted authorize URL including your client_id is provided for each application in the apps page.

Base url

All this things will make together a nice and understandable URI, like:

Small note: when formatting the scopes parameters, be sure to read above about the distinction between application-level and token-level scopes. this has been a point of friction for some developers.

42 redirects back to your site The 42 auth dialog

If the user grants the permission for your application to use the requested data (see scopes), it will be redirected to your redirect_uri with a temporary code in a GET code parameter as well as the state you provided in the previous step in a state parameter.

Exchange your code for an access token

You're almost here ! The last thing to do is a POST request to the https://api.intra.42.fr/oauth/token endpoint, with your client_id, your client_secret, the previous code and your redirect_uri. This request must be performed on server side, over a secure connexion.

Useless note: This corresponds to the token endpoint, section 3.2 of the OAuth 2 RFC. Happy ?

For example, with curl:

Make API requests with your token

Include your token in all your requests in a authorization header:

For example, you can fetch the current token owner, with curl:

If you can't modify http headers, you can send your token as a access_token parameter.
[null, {"document_url": "https://api.intra.42.fr/apidoc/guides/web_application_flow", "unformatted_src": "https://raw.githubusercontent.com/42School/api-documentation/master/images/authorize_dialog.png", "src": "https://raw.githubusercontent.com/42School/api-documentation/master/images/authorize_dialog.png", "formatted_filename": "authorize dialog", "alt_text": "auth_dialog"}, null]