erranddev / expo-authsession-authcodeflow

OAuth/ Authorization Code Flow with PKCE extension by Expo AuthSession

日本語 version はこちら

Example of Expo AuthSession

This repository is sample code for OAuth authorization flow(Authorization Code Flow with PKCE extension) By Expo AuthSession. This repository covers below topics.

1. Expo AuthSession on iOS and Web
2. Facebook OAuth
3. Twitter OAuth 2.0 (Twitter OAuth2)
4. Twitter OAuth 1-0a (Twitter 3-legged authorization)

Index

1. Demo
2. Conclusion
3. Glossary and Key Concept
4. Implicit Flow
5. Authorization Code Flow with PKCE extension
6. Build Environmental

Demo

demo.mov

Browser-based OAuth and Authorization Code Flow with PKCE extension

OAuth is all about enabling users to grant limited access to applications, and Browser-based OAuth handles these flow by browser and redirect-uri. Historically, OAuth is subject to privacy and security, so many practices have been considered by OSS.

Conclusion

1. Current best practice is Authorization Code Flow with PKCE extension(2022).
2. Process between Public Client and Authorization Server should be protected by state parameters against CSRF attack.
3. Redirect URI should be exact match between registered on Authorization Server and Public/ Confidential client.
4. Access tokens should not be exposed in the front channel. So Implicit Flow is not recommended.

Glossary and Key Concept

Three Players

Player	Descrioption	Example
Authorization Server	Authorization Server asks resource owner for authorization of access their resource to developer.	Facebook
Public Client	Public Client is User Interface which source code is readable. So Public Client must not have secret credential. Public Client request to Authorization Server for authorization of API access, and receive Authorization Response via Redirect Uri.	Web SPA/ Mobile Apps
Confidential Client	Confidential Client is backend server registered on Authorization Server, and has such info as client-id, client secret, permitted redirect uri and so on. Confidential Client requests Authorization Server for Access Token.	Your backend server

Two endpoints

endpoints	Descrioption
Authorization Endpoint	Authorization Server asks user for authorizing to access their resource by developer and then return user's answer(Authorization Response) such as Authorization Code to Puclic Client by Redirect URI.
Token Endpoint	Confidential Client requests Authorization Server to exchange Authorization Code for Access Token with registered credential info. After verify request, Authorization Server return Access Token to Confidential client by Redirect URI

Two well known Flows

Pattern	Descrioption	Recommended
Implicit Flow	Flow such as Puclic Client requests Access Token to Authorization Server, and recieves it in front channel.	No
Authorization Code Flow with PKCE extension	Public Client requests Authorization Server for short-lived Authorization Code in front channel. After Public Client passed it to Confidential Client, Confidential Client requests Authorization Server to exchange auth code for AccessToken in backend channel.	Yes

Implicit Flow

security risk of Implicit Flow

Access tokens should not be exposed in the front channel because of below risks.

• Interception of the Redirect URI
• Access Token Leak in Browser History
• Manipulation of Scripts
• Access Token Leak to Third Party Scripts

Authorization Code Flow with PKCE extension

what is difference from Implicit Flow?

• Authorization Code Flow with PKCE extension has Confidential Client and Token Endpoint which Implicit Flow dosen't have.
• Front Channel(Public Client) get Authorization Code which couldn't access api by itself.
• Confidential client(your registered backend server) exchanges Authorization Code for Access Token with Secret Key and PKCE. That is how your service dosen't expose access token in front channel.

use PKCE(Proof Key for Code Exchange)

1. PKCE is specification for verification that Both Authorization Endpoint and Token Endpoint are requested by same process.
2. Public Client generates random strings as codeVerifier, and make hash of it as codeChallenge by Sha-2 algorithm.
3. Public Client requests Authorization Endpoint with codeChallenge. That is how Authorization Server recognizes Who requested.
4. Confidential Client requests Token Endpoint with codeVerifier. That is how Authorization Server recognizes same process requested.
5. That is how oauth is protected against introspection of Authorization Response.

Reference

• The OAuth 2.0 Authorization Framework
• Proof Key for Code Exchange by OAuth Public Clients
• OAuth 2.0 for Browser-Based Apps

Build Development Environmental

Register Confidential/ Public Client

1. signup expo and get account name
   https://expo.dev/

2. twitter dev > User authentication settings
   https://developer.twitter.com/
   Register Redirect URIs https://auth.expo.io/@{Expo Account Name}/expo-authsession-authcodeflow, https://localhost:19006/twitterOAuth2, https://localhost:19006/

3. facebook dev > Facebook Login setting
   https://developers.facebook.com/
   Register Redirect URIs https://auth.expo.io/@{Expo Account Name}/expo-authsession-authcodeflow, https://localhost:19006/

create .env and set credential info

cp .env.sample .env
### you get credential info at Authorization Server(Twitter/ Facebook), and write them in .env

build local environmental

### clone source
git clone [email protected]:Minminzei/expo-authsession-authcodeflow.git
cd expo-authsession-authcodeflow
yarn

### docker
docker-compose up -d
docker-compose exec app bash
yarn server

### simulatar
yarn ios
yarn web