I've been reviewing how we should handle OAuth authentication in our browser application (SPA), and there's a whole bunch of articles out there that makes it all really confusing... I'm really missing something concrete and best practice guidance for a very simple setup.
We have this ASP.NET Web API 2 that's protected using tokens issued by IdSvr3. So far so good. Works with native clients and server apps.
Now to the browser stuff... Looking at a sample such as JavaScriptImplicitClient which uses the oidc-client-js library to retrieve tokens using the implicit flow. The token is stored in the browser which is accessible using JavaScript and there by open to XSS attacks.
In order to avoid that, suggestions indicates storing the token in a cookie and then setup a mechanism to prevent CSRF attacks.
Seems simple, but what sets that cookie?
Is it the IdSvr? Doesn't make sense since it's the API that needs the cookie.
Is it the API? During Implicit Flow login, are the user then redirected to the API which sets up the session and then redirects the user back to the SPA with a Set-Cookie header? Then the cookie will be present to the API on subsequent requests.
Third solution? Some is mentioning creating a second 'API' that proxies requests to the 'real' API, but sets the auth header.
Do you have any samples of such a setup, or can you maybe provide some hints about how you'd do it?
Personally, most of the times the avoidance of Web Storage for tokens due to XSS seems to be exacerbated a bit. There is one important question, if your application is vulnerable to XSS, will the impact of this vulnerability be significantly increased because you also leaked tokens or you already got totally pwned even if you didn't store tokens there and you're in the same type of trouble.
I made a comparison of the pros and cons of a few approaches to store access tokens in web browser application which you can check in this answer to a related question.
In the end each case ends up having their own specifics which may tip the balance between one approach versus the other (cookies or web storage). Just don't ignore any option from the start and look at all of them based on your requirements.
I bet that there are implementations out there that store them in HTTP-Only cookies to avoid the XSS issue with Web Storage and then end-up using a CSRF mitigation strategy that is vulnerable in the face of XSS.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
i am developing an application with Angular Frontend and Java/Spring-Backend. For logging into our backend we are using Oauth2 Authorization Code Flow with PKCE and Open ID Connect.
When the user navigates to a protected route he is redirected to his IDP and has to login. After that he is returned to a redirect_uri with the authorization_code as URL parameter. So far everything is clear.
Now I am not sure what the best way to exchange this code for the access_token is? So far I've done this on the client (in JavaScript) and used the received JWT for further backend calls (on the backend I just verify the signature) and that does seem to work. But in other projects I've seen that colleagues actually used the backend kind of like a proxy. So they send the authorization_code to the Java-backend and the backend does the exchange.
Now I've read a lot, but can't seem to grasp the full implications of that. It does seem to me that it's safer to have the client/frontend do this. But on the other hand the backend is actually trusted, so we could actually use a client_secret in this case.
The question now is: Are both cases considered safe? Or is one considered more secure and if so: why?
Thanks in advance
*Edit: Just to clarify - we don't really need to access another resource server, the use case is that we just want to be safely authenticated to our own backend - once authenticated we switch to a session cookie anyway, so we don't store the access_token anywhere at all
Keeping the tokens in the backend is always a more secure approach because it reduces the attack surface and makes the code in the client much simpler.
A good starting point is to take a look at this BCP
OAuth 2.0 for Browser-Based Apps (section 6.2)
Another reference is:
Cheat Sheet: OAuth for Browser-Based Applications (e.g. a JavaScript SPA)
To make your JavaScript simple, I would do all the client authentication in the backend and when the backend gets the token, then create the session with your client. In that way the JavaScript client does not need to touch any tokens. Your internal resources/API would be accessed through the service that is responsible for the session. Clean and simple! :-)
yes! I think the classic mistake is to let JavaScript touch your tokens. You will sleep much better at night knowing that the tokens are only handled in the backend. Also, less security complexity and things you must master and understand! We must fight complexity!
The actual authorization code can only be used once so it doesn't matter if it is sent from front end or back end.
There are two common models here:
OPTION 1: WEB BACK END / PROXY PATTERN
This is used if you want to keep tokens out of the browser and use HTTP only cookies as a back end credential instead:
Web back end issues a same domain HTTP only cookie and stores tokens in either a database or the cookie itself
Web UI makes all API calls by first calling the web back end with the cookie
Web back end then looks up tokens and forwards them to the API
You need to deal with web threats such as CSRF and XSS
Challenges are:
More complexity than you'd like
Some architecture limitations
OPTION 2: SPA PATTERN
This is the cross domain model you are using and is technically simpler up to a point::
Web UI makes API calls by sending an access token
You need to deal with threats such as XSS and focus in particular on ensuring that use of tokens in the browser is no less secure than use of cookies
You need to store tokens in a secure manner in the browser, such as in memory
Challenges are:
If you have gaps in your security they will be easier to exploit since users can more easily see their own tokens
Token renewal and cross tab navigation aspects are trickier in this model.
FACTORS
These are the main factors when making a choice:
Security threat model - tokens v cookies and other factors
Wider architecture goals for Web UIs
Perception of stakeholders is often the single biggest consideration
Whatever you decide I would recommend starting with requirements rather than a particular technology stack.
RESOURCES OF MINE
I prefer option 2 since I think the architectural options are far better, but it requires care. The following links hopefully help you understand how I reasoned out my preferred solution:
Web Architecture Goals
Threat Model - Cookies v Tokens
End State and Cloud Deployment
Not everyone agrees with me though. Sometimes in software there are multiple solutions. What is important is that security threats are covered. You can potentially do that with either solution.
When your are called token from your client it's not the authorization flow it's implicit flow, and it's could be used when you don't have backend, and when you have backend you always should use authorization code flow as you've mentioned. You can learn more about openid flows here.
Authorization code flow is considering more secured because it use backchannel communication(server to server) with idp for receiving tokens, while implicit flow send request from browser.
Sending client calls with PKCE is new technology and it's considered as safe but definitely authorization code flow is better choice for backend.
I have a website that exposes a public API. I want to secure this public API using OAuth 2. In order to minimize the number of code paths to maintain, I want to refactor my website to use the OAuth 2-secured public API endpoints.
The way I intend to do this is to register an OAuth 2 Client in my server as "my website", and then have that fetch a short-lived token. I see 2 problems with this approach:
My client would have to effectively have every scope, since the
website encompasses every possible action. The API is just a subset
of this (though I'm hoping to change that). The second issue is
security and caching of the token. The token would live for an hour.
If the user refreshes the page, do I fetch another token? If I store
it locally in a cookie or localStorage, is there a security
vulnerable of some sort?
Let's say I register a different OAuth Client for each page of my UI. The would make it so that the token in #2 would have limited scope if stolen, but it gets extremely tedious.
The alternative is to not use the public API on my website, and protection relies on CORS. Malicious attackers cannot access these endpoints because they are only allowed to come from the domain the user is on (and things like nonces).
Sounds like you want towards a model based on a Browser UI calling APIs directly, which is certainly the most attractive architecturally.
This may be the first step to a Single Page App architecture, which tends to provide the simplest and cleanest solution.
See Open Id Connect for browser apps for latest standards.
In an SPA the UI is cookieless and it is common to store short lived access tokens in HTML5 session storage, which means the user can refresh the page ok
It is true that all scopes are retrieved after login, but if you keep scopes simple and authorize in your API based on user rights you can mitigate that
The above token storage is the default behaviour for the certified OIDC Client Library and widely used.
There is a cross site scripting risk, that malicious content in your browser tab can get a token and call the API - but you should be protecting against this anyway.
Older solutions such as use of auth cookies tend to have their own (and bigger) risks such as cross site request forgery, where any malicious content in any browser tab can send the cookie to your API.
Evaluating whether to use HTML5 storage of tokens is about more than just the technical mechanism - it is about acceptable trade offs around usability and what can be done with the token. My blog post on UI token storage drills into this.
If it helps, my blog also has quite a few posts and code samples on SPAs, in case it is of interest.
I have been reading a lot about not saving the tokens in the user agent storage and I agree with the risks mentioned.
But going through some of the Auth0 quickstart examples, I see the tokens being saved in the session and using session cookies to track them.
Others mention saving the actual token as an httpOnly cookie with lower risks involved.
My questions are:
How is that considered stateless? especially with scalability and the potential use of load balancers.
Are the alternatives, memory cache and database stores? Is it that any different from sessions?
In the case of SPAs, how to maintain remember me functionality?
Asi Kavindu wrote, localStorage is a good place. If you want to protect the application against XSS attacks, use Content Security Policy, so a browser executes only your JavaScript code. There is a recent RFC about best practices for OAuth 2.0 and Browser-Based Apps, so you can check it.
If you want to keep state (session) on your backend with multiple backend nodes (cluster), you can use some shared data storage such as database or Hazelcast. The architecture is stateful in the same way as a single backend node with an in-memory session.
If you have a session on your backend and a cookie, you don't need an access token anymore, since yor SPA calls just your backend and the token would serve the same purpose as the session ID from the cookie.
The remember me functionality can be implemented using a cookie either at your authentication provider (probably better choice from the security standpoint) or your own application.
Architecture choices are usually trade-offs between simplicity and scalability. If you are just starting developing the application and not sure what to choose, I would go for simplicity, because even if you want to change it later, it should be easier to refactor.
Maintaining a session is applicable only when there is a backend to your application. From purely SPA perspective, storing a token in localstorage is acceptable and relatively secure. Modern browsers have capability to protect loaclsotrage compared to other means.
If you have a backend, correlating access token to a session is better than storing it in a cookie. Also one advantage you get get with this is the ability to get a refresh token, which can be stored in backend.
Having a cookie means loosing statelessness. Cookies are there to maintain a state between server and client end. Session maintaining require server resources but I do not think you need to worry much on that. Scaling must be done targeting your specific requirement.
Remember me functionality is yet again something built with cookies. It is a functionality provided by authorisation server. Think it as your browser remembering your Facebook's logged in status. It uses cookies and your application does not have to worry on that .!
We have a MVC application, in which we are making web api calls from browser to get the data and display it in browser. Since our application is Claims aware, the client need to pass AccessToken in order to access the web api.
Since the browser is not a trusted client (server does not have much control over browser), is it advisable for clients (browser) to store AccessToken? are there any better design patterns here without compromising security?
You'll have to trust the browser to some degree, otherwise your web application won't be of much use. Before tokens and API's, traditional server-side applications trusted that session identifiers could be stored by the browsers in cookies.
With tokens, the principle is the same, but the devil is on the details. First of all, assume HTTPS needs to be used, otherwise you might as well give up. Having HTTPS in-place, you can assume to some extent that sending the access token and/or cookies to the browser is secure.
After that, you need to worry about the characteristics of the storage the browser will use. For that I would recommend to read the Where to Store Tokens? section of the Cookies vs Tokens: The Definitive Guide article.
The real problem is that there are a sufficient number of other small details that is almost impossible to provide a definitive list and even though they are small details they can have very big impact on the overall security of the system. The only honest recommendation is that if you want to roll your own authentication system you need to be prepared so spend significant time and resources learning all these details.
I have been using Cookies for authentication and session control in my web apps, and am content with its functionalities.
I was introduced by an iOS app developer that the new hot thing is JWT (JSON Web Token). He told me that JWT is the way of doing authentication and sessions for native mobile apps, and without giving specific examples, he suggested that both iOS and Android apps have various problems with Cookies.
So I looked up JWT, e.g. http://angular-tips.com/blog/2014/05/json-web-tokens-introduction/ and https://auth0.com/blog/2014/01/07/angularjs-authentication-with-cookies-vs-token/, and I failed to see why it is significant better (or even that different) than Cookies, and more specifically, why it does better in native mobile apps. It seems that, at least iOS, handles Cookies just fine (Persisting Cookies In An iOS Application?).
So my question is, for a native mobile app that interacts with a server-side API, what are the specific advantages and associated use cases for using JWT over Cookies for authentication and sessions? Please highlight the ones that Cookies simply cannot do or does it much worse.
We software developers (sometimes) have the tendency to apply the new hot thing everywhere we look; it's possibly a variation of the saying if all we have is an hammer, everything looks like a nail where in this case we just feel a desperate urge to use this new thing we learned about.
One interesting point about this comparison is that neither JWT or Cookies are in fact authentication mechanisms on their own; the first just defines a token format and the second is an HTTP state management mechanism. Only this is sufficient to give us an indication that advocating that one is better than the other is wrong.
It's true however that both are vastly used in authentication systems.
Traditional server-side web application have used cookies to keep track of an authenticated user so that they were not forced to provide their credentials at every request. Normally, the content of the cookie would be an (hopefully) random generated unique identifier that the server would use to find session data stored on the server.
However, for a new type of web application - the API - it's more much more common to accept a token (in JWT format most of the times) as a way for the server to decide if it should grant access to who's making the request. The reason for this is possibly because while a traditional web application had one major type of client, the web browser, which has full support for cookies, the API's are generally used by much simpler HTTP clients that don't natively support cookies.
I think this is also why we could possibly argue that token based authentication makes more sense for native mobile applications. These applications generally depend on a server-side Web API and we've seen that if the API supports tokens it will increase the range of clients that can use it, so it's just the most practical thing to do.
In conclusion and to try to answer your concrete question, I would say JWT's do have an advantage over cookies on native mobile applications just because of the fact they are currently in very common use, this means more learning resources, SDK's, known pitfalls (mostly because someone else already did it and failed), etc.
Nonetheless, only use them if they give you the security assurances you need and end up simplifying your scenario. If you haven't gone through it already, I think you'll also appreciate Cookies vs Tokens: The Definitive Guide.
I cannot speak for Android but on iOS cookies work with URLSession as good as headers. Once you can utilize the (standard) API right (e.g. dedicated, properly configured session with cookie storage per web app...), iOS should be a rather negligible factor to this decision.