Yohoho! I am building an application that leverages OAuth to pull user data from provider APIs, and am wondering about the RFC compliance of the flow I have chosen.
Currently, the user signs into the authorization server which sends an auth code to my frontend client. The frontend then passes the auth code to my backend, which exchanges it for an auth token and then makes calls to the provider to pull data.
In this best practices document, it states:
Note: although PKCE so far was recommended as a mechanism to protect
native apps, this advice applies to all kinds of OAuth clients,
including web applications.
To my understanding, PKCE is designed to ensure the token is granted to the same entity that requested the auth code, in order to prevent attackers from using stolen auth codes to execute unwarranted requests.
Now, it makes sense to me why this is important even if the backend keeps the client secret unexposed, since the attacker can make requests to the backend with the intercepted auth code to receive the token. However in my flow, since I am not creating an authentication scheme and rather trying to authorize premeditated requests, the token stays with the backend.
So why is PKCE recommended here? It seems to me the most a stolen auth code can do is initiate an API request from the backend, with no token or data being returned to the attacker. And assuming a PKCE implementation is the way to go, how exactly would it work? The frontend requesting the auth code and the backend trading it for a token aren't exactly the same, so would it be as simple as passing the code_verifier to the backend to make the call?
Some clarification would be greatly appreciated.
PKCE ensures that the party who started the login is also completing it, and there are two main variations that I'll summarise below in terms of Single Page Apps (SPA).
PUBLIC CLIENTS
Consider a Single Page App that runs a code flow implemented only in Javascript. This would store a code verifier in session storage during the OpenID Connect redirect. Upon return to the app after login, this would be sent, along with the authorization code and state to the Authorization Server.
This would return tokens to the browser. If there was a Cross Site Scripting vulnerability, the flow could be abused. In particular the malicious code could spin up a hidden iframe and use prompt=none to get tokens silently.
CONFIDENTIAL CLIENTS
Therefore the current best practice for Single Page Apps is to use a Backend for Frontend (BFF), and never return tokens to the browser. In this model it is more natural for the BFF to operate like a traditional OpenID Connect website, where both the state and code_verifier are stored in a login cookie that lasts for the duration of the sign-in process.
If there was a Cross Site Scripting vulnerability, then session riding is possible by the malicious code, to send the authorization code to the BFF and complete a login. However, this would just result in writing secure cookies that the browser cannot access. Similarly, the hidden iframe hack would also only rewrite cookies.
The code_verifier could alternatively be stored in session storage and sent from the browser to the BFF, but it would be easy enough for malicious code to grab it and also send it to the server. This does not really change the risks, and the key point is that no tokens should be returned to the browser. It is OK to use secondary security values in the browser, as long as you can justify them, eg for security reviewers. Generally though it is easier to explain if secure values are in secure cookies and less visible to Javascript.
FURTHER INFO
Best practices often vary depending on the customer use case, and at Curity we provide resources for customers (and general readers) to explain secure design patterns. These are based on security standards and we translate them to customer use cases. You may
find our recent SPA Security Whitepaper useful.
Related
I've got an OAuth2-driven authorization system for the applications in my ecosystem using the Auth Code flow. At the moment, it is working extremely well following what I feel are best practices. My current flow can be summed up as this:
User clicks a Login button in application frontend.
Backend for application redirects user to Auth Server login page with redirect URI, client ID, etc, in params.
User logs in, Auth Server redirects to Backend /authcode endpoint with Authorization Code.
Backend authenticates with Authorization Code, receives Access (JWT) & Refresh tokens. It stores Refresh token in its own database, and returns Access token as an HTTP-Only cookie.
When Access token expires, Backend sends Refresh token to Auth Server to refresh.
The problem with this approach is it is heavily dependent on a single-backend/monolith/etc architecture. When the access token expires, the backend app in question needs to be able to get the refresh token and then do the refresh against the Auth Server.
My goals for the future state of this architecture are driven by two main concerns:
Allowing backends to be split into multiple micro-services that are all capable of authenticating the same JWT.
Supporting SSO. Currently, even though all users are managed through the same Auth Server and use the same credentials, they need to enter those credentials separately for each app they log into.
My initial thought was to move the refresh handling to the client-side part of the architecture. Since all the apps are owned by me, I could setup a new flow where a user would login directly with the Auth Server, and then the Access (JWT) and Refresh tokens are set as HTTP Only cookies. This is further supported by the fact that all of my apps are hosted via a single domain name (with different root URI paths for different apps). The new token structure would determine which apps a given user has access to.
My concern there is how to secure the Refresh Token client-side. Most likely I would need to use the Path attribute and depend on the fact that all my apps are on the same hostname, which as I said they are and that will not be changing.
I guess the point of this post is I'm looking for guidance on best practices for handling this kind of scenario.
A few thoughts based on design patterns we recommend at Curity:
BACKENDS AND JWTs
Related APIs should be able to forward JWT access tokens to each other, as detailed in the scopes article. Validating the JWT in each API results in a recommended zero trust setup.
BACK END FOR FRONT END
We recommend a particular way of doing this, focused on separation of web and API concerns - see this code example on the token handler pattern.
Token refresh is handled via HTTP Only cookies and client side retries. This provides a stateless solution that is easy to manage, and where the web back end is static content only, eg a content delivery network. It requires a couple utility API components to be deployed though.
An alternative option, as you say, is to write code within your back end to store tokens, so that cookies only contain a Session ID.
COOKIES AND MULTIPLE WEB APPS
In our resources we use reverse proxies / API gateways as the entry point to APIs, rather than a web back end. Common plumbing such as translating cookies to tokens can then be managed via gateway plugins - as covered in this tutorial.
However, when you have multiple web apps you need to keep cookies isolated during API requests. Each app therefore needs its own API routes. This is awkward but is a consequence of needing to use secure cookies for best browser security. It is best managed in the gateway, and separate domains or subdomains is usually cleanest:
https://api.brand1.com
https://api.brand2.com
Each web team is then responsible for their own API routes and the cookie / CORS / CSRF stuff, rather than the API developers.
SSO
This should be determined solely by the Identity Provider session cookie, which will remain valid as you navigate across apps. If you are presenting a login button when the app does not have a secure cookie yet, then it will not feel like SSO though. One technique for making SSO look seamless is for each app to automatically redirect when it does not have application cookies yet, rather than presenting a login button.
SUMMARY
A long answer, but the best solutions require separation of concerns that is not always obvious. Done well, the end result should be simple code in apps, correct security and an architecture that can be scaled.
I understand the Oauth code flow which involves the mobile app, app server, auth server, resource server. The app server is registered with auth server using the clientidand secret. The idea being that mobile app calls an endpoint of the app server which triggers the code flow eventually resulting in callback from the auth server to the app server with the auth code. The app server presents the secret and code to auth server to get the access token.
The other legacy option where there is no clientid and secret is the implicit flow wherein the mobile app receives the redirect url with the auth code (assuming redirect url destination is a SPA) which will invoke auth server endpoint to get the access token.
This is insecure because anyone can steal the access code from the url.
The solution to this for clients like mobile app is to use pkce. A random number hash is sent in the initial request which is verified later on when the auth code is passed to retrieve the access token.
This prevents the compromise of the access code from the url if an attacker is snooping because without initial hash the auth code is useless.
However how can the situation where the mobile phone is hacked and the secret and auth code is recorded by an attacker be handled to prevent misuse?
However how can the situation where the mobile phone is hacked and the
secret and auth code is recorded by an attacker be handled to prevent
misuse?
This is out of scope for OAuth 2.0 & related specifications. This issue is similar to storing encryption details in a server, but still, the server can be attacked by gaining physical access. It's a different attack vector altogether. It is user's duty to make sure their devices are safe from other vulnerabilities.
However, PKCE provides an extra security layer for public clients' usage of OAuth flow. It prevents attacks based on redirect (authorization code stealing), by establishing secondary validation at the authorization server.
In general, read through OAuth 2.0 Threat Model and Security Considerations & OAuth 2.0 for Native Apps for best practice suggestions.
These are the standard options:
PKCE uses a different code_verifier and code_challenge for every login attempt. If an authorization code is somehow captured from the system browser by an attacker it cannot be exhanged for tokens. No client secret is used, since a mobile app is a public client.
Use HTTPS redirect URIs (based on mobile deep links) so that if an attacker steals your client_id and redirect_uri they cannot receive the response containing the authorization code and will not be able to get tokens.
See this previous answer of mine for some further details, though claimed HTTPS schemes are tricky to implement.
Of course if an attacker has full control over a device, including authentication factors such as autofilled passwords, there may still be attack vectors
In Oauth Open ID - Authorization Code grant type flow,
We will call the Oauth service provider with the client_id = '..', redirect_uri='...', response_type='code', scope='...', state='...'.
Then from Oauth Service Provider, we will get the authorization code instead of the token.
Q1. So what is the next step? Do we send the code to the back end where the token request will happen or will we call the Oauth service provider from the browser it self?
Q2. Why do we need this additional calls? what problem it is solving?
Q3 After the token is received, how we use it in a typical web application?
p.s: I have read lot of blogs, but unable to get the whole picture. Could you please help me?
Q1. In 2021 it is recommended to keep tokens out of the browser, so send the code to the back end, which will exchange it for tokens and issue secure SameSite HTTP Only cookies to the browser. The cookies can contain tokens if they are strongly encrypted.
Q2. The separation is to protect against browser attacks, where login redirects take place. An authorization code can only be used once but can potentially be intercepted - by a 'man in the browser' - eg some kind of plugin or malicious code. If this happens then the attacker cannot exchange it for tokens since a code_verifier and client_secret are also needed.
Q3. The token is sent from the browser to APIs, but the browser cannot store tokens securely. So it is recommended to unpack tokens from cookies in a server side component, such as a reverse proxy. This limits the scope for tokens to be intercepted in the browser, and also deals well with token renewal, page reloads and multi tab browsing.
APPROACHES
The above type of solution can be implemented in two different ways:
Use a website based technology that does OAuth work and also serves web content
Use an SPA and implement OAuth work in an API driven manner
Unfortunately OAuth / OpenID in the browser is difficult. At Curity we have provided some resources based on the benefit of our experience, and we hope that this provides a 'whole picture' view of overall behaviour for modern browser based apps:
Code
Docs
I'm trying to allow access to our publicly facing APIs to approved Single Page Applications only.
We currently use OAuth 2.0 to control access to our APIs. The high level scenario is that our users will access our publicly available SPA, provide their username and password, and then be able to use the SPA which in turn will be able to use our APIs.
The current best practice for OAuth 2.0 with SPA is to use the authorisation code grant with a client id but without the client secret, as obviously an SPA cannot keep any secrets.
My question is how can we prevent a third party SPA from accessing our APIs. I.e. they could extract the existing client_id from our SPA and request an authorisation code in the same way as our first party SPA. Assuming they can persuade a user to login they can then access our APIs.
Is the pre-registered redirect URL the only defence in this scenario? If so, does that mean that if we switch to using the resource owner credentials grant for a better user experience (not recommended I know) there would be no protection from third party apps at all?
I've read the various RFCs for OAuth and this page in particular is very useful but doesn't quite answer my question:
https://auth0.com/blog/oauth2-implicit-grant-and-spa/
Indeed the pre-registered Redirect URI is the only defense mechanism in this case of a public Client when using the so-called Implicit grant type. An attacker may trick the user in starting the flow but will not receive the issued token on a Redirect URL that it controls. This is similar to tricking the user into starting any other login flow.
Since the attacker does not obtain a token (it is still delivered on the intended Redirect URI controlled by the Client) he cannot access your APIs, even if he can persuade the user to login.
When the attacker controls DNS things become more dangerous but that goes for a lot of things outside of OAuth 2.0 as well. In general: delivering tokens to an in-browser app is going to suffer from this type of vulnerability regardless of the protocol used.
Switching to Resource Owner Password Credentials has a lot of drawbacks, including one where the attacker can present an app similar to yours to obtain the username/password (which also block you from upgrading to multi-factor authentication as the other grant types would allow you to).
In summary: there is protection against it although not super strong.
FWIW: the latest OAuth 2.0 best practices suggest that tokens should no longer be directly delivered to the Redirect URI but use an intermediate short-loved one-time usage Authorization Code instead to allow the SPA to get its tokens in an XHR call directly from the token endpoint.
After watching an obscene amount of tutorials on OAuth2, there is one best practice that everyone repeatedly states - if you have a React app (or Angular, or Ember) - you must use Implicit flow with it.
I understand that storing client credentials in publicly visible javascript would not work. However, my scenario is a bit different:
I'm only using Oauth2 for single sign on and token generation for microservices. I chose it instead of simply generating tokens, since well-supported third party libraries are built around the Oauth2 idea.
My idea is to have a React app, and a ASP.NET MVC app which serves the javascript and acts as a proxy for API requests. The user authenticates for the server-side app (by using Oauth2 authorization code flow).
Then if I need to retrieve data from an API, I call my ASP.NET MVC app from React (by sending a simple cookie). The MVC app holds the token without ever exposing it to the user's browser.
Obviously, when called, my MVC app then redirects the request to the necessary API, providing the bearer token.
To better understand why this is what I came up with, here are some requirements I've received that might be unusual:
I really don't want the access token to be shared - even if it's relatively short lived.
I also want to be able to limit each user account to 3 concurrent user sessions. Easy to do using cookies and server-side sessions.
I can't wrap my head around why this idea would be that bad. Is there any technical problem that might prevent this from working? Or maybe a security risk?
The authorization code flow returns an authorization code (like it says on the tin) that can then be exchanged for an ID token and access token. This requires client authentication using a client id and secret to retrieve the tokens from the back end and has the benefit of not exposing tokens to the User Agent.
This flow allows for long lived access (through the use of refresh tokens).
Clients using this flow must be able to maintain a secret.
Accordingly to your description, you have service-to-service authorization flow, and as your service are not exposing client secret key it is totally OK to use the Code flow. Moreover, you should use it to allow long lived tokens.