PKCE

Fri, 03 Dec 2021 00:00:00 +0000

PKCE is pronounced as ‘pixie’. PKCE - Proof Key for Code Exchange => Credits

Concepts:

What is Confidential Client?

Any backend application written in languages like .Net, Java, NodeJS can be considered as Confidential Client. As they have the ability to “store variables” in our case Secret Keys - without exposing them to the end user - as the code is running on the server side. The secret key would be used to generate the Access Token in the OAuth Flow.

What is public Client?

Any Single Page Application (SPA), where all the code is downloaded to the users browser would be considered a Public Client. Coz: the secret key cannot be securely stored as the hacker could do a “view source code” and look at the secret key which is usually in plain text/string format.
Another example are Mobile Apps - the user can download and de-compile/reverse engineer - the application and find the secret key.

Why do you need PKCE?

Once the secret key is available - the hacker can impersonate as the Client and generate the access token (note: clientID is public and secret key is private). Once the access token is available - the hacker can access lot more confidential information about the user. So the existing OAuth2.0 model is not secure for both SPA and mobile apps. To solve this challenge - PKCE was introduced.

OAuth 2.0 Normal Flow:

PKCE Flow:

What is new in PKCE?

In the PKCE flow: Instead of a constant Secret Key - Everytime an OAuth flow is initiated - A new “Secret Key” is generated and Hashed.
Hash is shared with the Authentication Server(AS) when requesting for the Temporary Code. AS would remember this Hash value.
When the client request for the Access Token - it sends the newly generated “Secret Key” - the AS would check, if the secret matches the Hash (it already remembers - #2).

Reference:

RFC7636, Oauth Hack, What’s the difference between Confidential and Public clients

Designated Authentication - OAuth2.0

Thu, 02 Dec 2021 00:00:00 +0000

OAuth2.0 and OpenID - is one of the best videos (62 mins) on this topic - Highly recommended. This blog is just a quick summary (4 mins read) of it.

What is OAuth?

OAuth is a security standard where you give one application permission to access your data from another application i.e. you authorized one application to use data from another application on your behalf, without giving them your username and password. The steps to grant permission(s) or consent is often reffered to as authorization or delegated authorization. Permissions are scoped e.g. client can be given access to read your GMail contacts but cannot Read/Write your email. OAuth is not exactly used for user identification (who loggged in), instead its used to access API’s for resources like gmail contact list.

You check-in to a hotel.
At the front desk - You give your details like Passport and Reservation
Front Desk would in turn - give you the Key Card i.e. Access Token
You can use the Key Card to access your reserved Room

Here, the Front Desk is the Authentication Server - the key card is your Access token used to acess your Room (Resources API). The API doesn’t really care who is accessing the Resource as long as they have the access token.

OAuth Terminologies:

Lets assume you are giving Yelp access to your Gmail account contacts..

Resource Owner: Represent you the owner of the gmail account; who can give permission/authorize.
Client: Represent Yelp i.e. the application which would like to perform action on behalf of you.
Authorization Server: One who validates the gmail uname/password and authenticate - in this case accounts.google.com. Resource owner will already have an account with this server (gmail).
Resource Server: Server (API) which has the actual content/resources like contact list in this case contacts.google.com. Which client would talk to get the actual data.
Authorization Grant: Once authenticated an Authorizatiion Code or temporary code is sent back to he client. So, the client has been granted relevant access to the resource owners gmail contacts. This is short lived, this is used to inturn get the access token (long lived).
Redirect URI: Also known as Callback. It is the URI to which the response of Authentication #5 should be sent back to client #2
Access Token: Token/Key used by the Client to access all the resources of the owner; based on the authorized permissions.
Response Type: The type of information the client would like to receive e.g: code (authorization code)
Scope: Granular permission the client wants acess to like Read Contact, Read Profile basic info.
Consent: Whether the client can be given permission to access the requested information.
ClientID: Unique ID of the client, which is used to talk to the authorization server.
Client Secret: Secret Key - only the client and the auth server shares. Helps Client and Resource Server to share information secretly behind the scenes.

OAuth Flow:

Prerequisite:

Client and the Authorization Server should establish a working relationship. Both the “ClientID (AppID)” and “Client Secret(AppSecret)” are generated by the Authorization Server. The client ID would be used to uniquely identify the client. Its the responsibility of the client to ensure the “ClientSecret” is kept secret and its only know by client and authorization server. As there are the only means for the Auth Server to verify the client.

Actual Flow:

In this example, Yelp would want to authenticate a user based on GMail Authentication, and access Profile/Contacts information.

Client(Yelp) would make a request to Authenticate - to “Autorization Server” (accounts.google.com); as part of the request:
1. “RedirectURI” is set to a callback URL of the client “yelp.com/callback”
2. “Respose Type” is set to “Code”, so a auth code is sent back as response to 1.a
3. “Client ID” and “Scope” (Profile/Contacts)
Auth Server pops up a dialog (mostly) - where user gets to enter the GMail credentials (uname/pass) and authenticate
Auth Server shows up a consent form - list the info access requested (like contacts, profile) - user gets to choose Yes or NO
Once concent(Yes) is given - an “Auth Code” is generated and sent back to the the client - to specifiied callback/redirectURI.
Then, the client sends the “Auth Code + ClientID + ClientSecret” to “Authorization Server” and gets back an “Access Token”
Using the “Access Token”, Client can contact the resource server (contacts.google.com) to get the actual resources (profile, contacts) of the user.

Reference: https://www.youtube.com/watch?v=aU9RsE4fcRM

Security | Jacob Aloysious