2

What is the proper way of combining session-based authentication with stateless, token-based authentication for a REST API?

Use case:

  1. User logs-in in the standard, traditional, session-based way. Most of the website uses this login flow.
  2. On one of the pages, a JavaScript script wants to request some data from a RESTful stateless API on behalf of the user

I expect the JavaScript script will need to be given something in the page (e.g. in meta tags) as the page loads to be able to authenticate with the API. The API uses OAuth2.

What should it be and how best to give it to JavaScript?

  • The code in the Authorization Code grant? This would mean JavaScript will have to make another authorization request to get the access token.
  • The access token itself? This feels insecure, outputting the access token into the HTML of the page.
  • Something else?

How to give it to JavaScript?

  • Meta tag?
  • Headers?
  • Something else?

The OAuth documentation / tutorials are really unclear about this.

  • IMO this is borderline offtopic. Anyhow, this is a design question. For any engineering/design the first thing you need to know is: what do i want and explicitly not want? Then look at the available options and evaluate how well they serve your needs defined previously. Please add to the question: what are your needs; which options did you consider? why do none of them work for you? – marstato Nov 12 at 10:34
3

So "standard, traditional, session-based" auth is a cookie on the client with a guid and an in memory database on the server which hold the data for that user

"stateless, token-based authentication" just takes the data on the server, puts it in the cookie and signs it.

All you need to do is have the server create a token and send it to the client instead of the sessionid cookie. You can put the info in a cookie.

  • Sounds good. But then the access token, being in the cookie, will be sent with every request to the server, not just to the API (which knows not to tamper with it), but to every page (where anything can happen to a helpless cookie). But if this is the way it is done, then maybe I just worry too much. – Ian Pollak Nov 4 at 17:52
  • which mean you can use it instead of the sessionid and its accesible to the javascript – Ewan Nov 4 at 18:02
1

This article walks through various ways to use OAuth2. It might help you work through this.

Based on the article and the relevant RFC, you would not pass the access token to the user agent (e.g. browser). The authorization grant is passed to the client (web server) and it then uses the authorization code to retrieve the access token directly.

The other option that seems relevant here is the implicit grant style. In this case the access token is indeed provided back to the user agent in a redirect URI. You can potentially improve on this slightly by passing the token in a header instead of the URI as noted in the article. The use of headers here aligns with OWASP recommendations.

So more or less, it seems you are on the right track, you just need to choose between the extra overhead of having the client web server call for the access token or the potential risk of passing the access token back to the user's browser. The length of time the access tokens and authorization grants are valid is important to consider when weighing the options.

Be sure to check the end of the article as it discusses some ways to avoid pitfalls in either approach.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.