CODEWITHSUNDEEP
oauth-2.0
phanin
phanin

Reputation: 5487

Why protect authorization code using PKCE in native apps? What protects access token thereafter?

"The Authorization Code Grant has some security issues, when implemented on native applications. For instance, a malicious attacker can intercept the authorization_code returned by Authorization Server and exchange it for an Access Token (and possibly a Refresh Token)." Ref: Auth0

If I understand the article correctly, we go to great lengths to protect the exchange of authorization code and access code in native apps using PKCE.

The premise here is that an attacker "can" actually intercept the authorization code. So we use PKCE to protect it. But what's stopping the attacker from intercepting the access token?

Edit: Please ignore the following as it seemed to confuse other readers by being ambiguous. "What's the point of additional PKCE protection here and what's the point of the 2 step process (get auth token and then the access token) when there's no back channel."

[New to OAuth2]

Upvotes: 4

Views: 873

Answers (2)

rawel
rawel

Reputation: 3033

The access token is short lived. So if access token happened to be on wrong hands they will not be able to use it for a long time. But if the authorization code is on wrong hands, it can be used to get access token/refresh token for a longer period. Please note that this access token is not for a protected resource of the app but for a protected resource of the user. So the app should try to protect its best to prevent authorization code falling on wrong hands.

With PKCE, the authorization code can only be used with code_challenge and code_verifier(article) So by just using authorization_code attacker can't get an access token on behalf of the user as he doesn't process the code_verifier

Edit:- The insecurity of authorization flow comes with the fact that there is no way you can protect client id and client secret in a mobile device. So an attacker can simply steal your app's client id and secret. But he cannot use just that to access a protected resource of a user without user's consent. An authorization code is issued with users consent only. So if that code has fallen to attackers hand attacker has all parameters to use that to get access_token and refresh_token and access user's protected resources without user knowing. PKCE trying to prevent that type of attacks.

Upvotes: 1

Kavindu Dodanduwa
Kavindu Dodanduwa

Reputation: 13059

What's the point of additional PKCE protection here and what's the point of the 2 step process (get auth token and then the access token) when there's no back channel.

What PKCE protects is the front channel authorization code response. Here front channel means the usage of user agent (browser).

When your application runs on a machine (ex:- Mobile phone, desktop or pc), it is not possible to protect embedded secrets. Malicious party can decompile source code and extract embedded passwords. Because of this, OAuth token request cannot be password protected.

Adding to this, user agent can be intercepted by any malicious party (think about a browser extension). Thus there is no native protection for authorization response.

To overcome this, PKCE - RFC7636 provide a mechanism to bind authorization request with token request. In very abstract manner,

  1. Generate a secret (in-memory so hard to extract at runtime) at application
  2. Hash it and include it in front channel (browser based) authorization request
  3. Authorization server will correlate hash value to authorization code sent in authorization response
  4. Include secret in token request so authorization server can validate

Now, even when malicious party intercept authorization request, secret is hashed. So they cannot request tokens.! Secret is in-memory which make it difficult to extract.!

Token request occur in back-channel. Which is independent of browser (a direct http call to authorization server). Which is protected compared to browser based connections.

Hope it's clear now

Extra information - Token request can include client id and client secret. Including client secret make things more secure. But as I have highlighted, native applications (pc, mobile sort of apps) cannot have embedded secrets. Thus PKCE add an additional security layer .!

Upvotes: 6

Related Questions