
## Background

Logging in to a web service used to mean sending a username and password and
getting a cookie in return. This cookie is then sent with every request so that
the server knows who is making the request. However, when it became more common
for services to interact with each other on a user's behalf, other forms of
authorization systems evolved. One such system is OAuth, which uses
token-based authentication instead of cookies.

OAuth is an __Authorization__ framework that allows three different parties to
interact with a minimum level of trust. This way only one service needs to know
your username and password. The service that doesn’t store this information
can ask the service that does to verify who the user is and what they are allowed
to do. In general, this provides a better, more secure, user experience.
A user can maintain their profile and password information in a single place
and have that referenced automatically when they connect to other services. No
more typing in email addresses to every site and updating it in multiple places
if it changes. This is how __Login with Facebook__ or __Login with Google__
buttons work.

Unfortunately, there are a couple of inherent security risks with this approach.
One service is not as trustworthy as another. You might want to allow that
budgeting app to read your account balance, but you probably don’t want it to
empty your checking account. Additionally, the first time services
communicate they must go over a public network where anybody can be listening.

In order to protect the credentials and limit what those credentials can do
some initial trust needs to be bootstrapped ahead of time. This
is done by combining two different components to ensure that the
recipient of a temporary public credential is, in fact, the one it is intended
for. If you have heard of two-factor authentication __(2FA)__, it's like that but
for web services.

There are a couple of methods that use this combination of factors to provide
some extra confidence the service getting access is the right one. We’ll take a
look at two of those; __Authorization Code Flow__ and
__Proof of Key Code Exchange__.

## Authorization Code Flow

_Protection by Proxy_

__Authorization code__ flow is the classic way to do this when a client that has a
server component. This server component protects an OAuth __client secret__ and
proxies the token request from the client to the __Authorization Server__. In this
flow, a user is redirected from the service hosting the protected resources to
an __Authorization Server__. The __Authorization Server’s__ job is to authenticate the
user and approve access. After successfully authenticating, usually with a
username and password, the user is redirected back to the service with some
extra URL parameters including an __authorization code__.

The __authorization code__ is a temporary code needed to retrieve the __access token__
for permission to interact with the __relying service's__ resources. The __relying
service__ then exchanges the __authorization code__ combined with their __client id__ and
__client secret__ for an __access token__ and optionally a __refresh token__. The __relying
service__ then returns these to the user's client, usually a browser or mobile
application. The client then uses this token to tell the __resource server__ who
the request is for and what permissions they have.

![Authorization Code Flow](/images/posts/auth-code-flow.png)

## Proof of Key Code Exchange (PKCE)
_Cryptographic Pixie Dust_

With the rise and popularity of mobile apps and Single Page Applications (SPA) a new
flow had to evolve to accomodate public clients. These clients cannot properly
protect a __client secret__ since they run in an environment not controlled by the
application owner. These are often either a mobile device or JavaScript in the browser. To
compensate for the lack of confidentiality the flow extends the __authorization
code__ flow using cryptography to generate a __code verifier__ and a __code challenge__
for every __authorization code__ exchange.  During the request to get an
__authorization code__ the __relying service__ includes the __code challenge__. Then when
the __relying service__ receives the __authorization code__ it exchanges that in
addition to the __code verifier__. The __authorization server__ then uses the __verifier__
to confirm the original __code challenge__.

![PKCE Flow](/images/posts/pkce-flow.png)


## Why not exchange the password for a token?

Exchanging the password for a token is called the __Resource Owner Credential
Flow__. This flow is not recommended unless there is a HIGH level of trust between
the __Authorization Server__ and the client. When the client is JavaScript or a
mobile app the trust just isn’t there. The previous flows allow the for
interaction outside of the initial client for exchanging the password with the
__Authorization Server__. For example, on a mobile device, the application might
open a browser to begin the exchange and finish at an app-specific URL to
complete it. This way the mobile application never has to handle the username
and password directly.

## What does this buy us?

In both __Authorization Code__ and __PKCE__ flows, two factors must be exchanged for valid
credentials. The __authorization code__, as presented as part of a redirect URL for
consumption, along with some additional information posted in the body of the
__access token__ request. These two channels of communication mitigate a variety of
attacks and misconfigurations where bearer tokens or authorization can be
intercepted in flight.

However, with __PKCE__ there is one more consideration to take into account and that
is where the __Authorization Server__ redirects after authentication. The client
tells the __Authorization Server__ where it wants to receive the code in the URL. If
this is not an exact match, it means there is an opening for a malicious client
to trick the __Authorization Server__ to send the code somewhere else. That same
client can also generate the temporary secret code.  While __PKCE__ moves the
goalposts in terms of difficulty, it still relies on this redirect as an anchor
of trust.

While having a fully qualified redirect URL is a best practice,
__Authorization Code__ flow mitigates an open redirect misconfiguration due to the
fact that the server still holds a predetermined secret. Because the secret used
in __PKCE__ is generated at runtime, a malicious actor capitalizing on an open
redirect can still follow to the protocol to get valid credentials. On mobile
clients, this is an app-specific URL such as
`app-foo://auth_code_handler#code=XXX`. For SPA’s this would be something like
`https://app.foo.com#code=XXX`.

While __PKCE__ was originally intended for mobile applications the [OAuth Best
Practices Working Group](https://tools.ietf.org/html/draft-ietf-oauth-security-topics-11#section-2.1.1)
has recently started to recommend it for SPA’s as well.

To add a __PKCE__ flow to your application take a look at https://appauth.io/ for
supported libraries and implementations.


Grant Callaghan

1 Article from Grant Callaghan

PKCE vs Proxy

Get the newsletter