• https://api.intra.42.fr/apidoc/guides/web_application_flow
• https://auth0.com/intro-to-iam/what-is-oauth-2#how-does-oauth-20-work
• https://auth0.com/docs/authenticate/protocols/oauth

1. Authorisation grants

RFC 6749 defines 4 types of grants used by the client to obtain an access token as well as an extensibility mechanism for defining additional types (not seen in the 42 API documentation). Since we are building a single page application we will use the Authorization Code grant type with PKCE

1. 1. Authorisation Code (for apps running on a web server)

diagram

concerns: authorization code is visible in the browser

1. 2. Implicit (for clients without a secret, but now they should use the Authorization Code grant with PKCE)

diagram

1. 3. Ressource Owner Credentials (only for first-party apps)

diagram

1. 4. Client Credentials (for application access without a user present)

diagram

2. the PKCE-enhanced Authorisation Code Flow

OAuth 2.0 public clients utilizing the Authorization Code Grant are susceptible to the authorization code interception attack. The RFC7636 describes the attack as well as a technique to mitigate against the threat through the use of PKCE

1. create a url with a random code

the url contains:

2. 1. client_id of 42 API

• can be seen in the intra / API app we created
• setup as environment variable

2. 2. redirect uri

• can be seen in the intra / API app we created
• hardcoded as 'https://localhost:8000/callback'

2. 3. scope

• can be seen in the intra / API app we created
• hardcoded as 'public' since we do not need any other authorisation

2. 4. state: a random string different for each oauth2 workflow

• is generated in backend

2. 5. response type:

according to RFC 6749 Section 3.1.1, it can have either the value

• "code" for Authorization Code Grant
• "token" for Implicit Grant
• some other key for registred extensions which is not used by the 42 api)

4. Same Origin Policy

We use Cross Origin Ressource Sharinge (CORS) for the intra