Solution validation

Help
, , , ,
1

For a variety of reason we cannot use Auth0 lock or have client talk to Auth0 directly, as such, is the following proposed solution acceptable from a security point of view.

Our application consists of an SPA and native mobile apps that talk to a single API. Everything is over HTTPS.

For the SPA:

  • The users enters username/password into the SPA and sends these to our API.
  • Our API makes a request to Auth0 to get an access_token (JWT) and refresh_token via /oauth/token.
  • The access_token is passed to the SPA along with a session id.
  • The SPA stores the JWT in localStorage.
  • The session id is in an HTTP only cookie.
  • The refresh_token is stored on our secure API server and scoped to the users session.
  • All subsequent requests pass the access_token (JWT) as a Authorization (bearer) header and the session id as a cookie implicitly.
  • If the access_token (JWT) has expired a 401 is returned to the SPA.
  • The SPA makes a request to a refresh endpoint and passes to it the session id and access_token (JWT), the session id is used to look up the refresh token from the session storage and a new access_token (JWT) is requested from Auth0.
  • The new access_token (JWT) is then passed back to the SPA.

For the native mobile apps:

  • The users enters username/password into the app and sends these to our API.
  • Our API makes a request to Auth0 to get an access_token (JWT) and refresh_token via /oauth/token.
  • Both the access_token (JWT) and refresh_token are passed back to the mobile app with nothing stored on our servers.
  • All subsequent requests pass the access_token (JWT).
  • If the access_token (JWT) has expired a 401 is returned to the mobile app.
  • The mobile app makes a request to a refresh endpoint and passes both the access_token (JWT) and the refresh_token, the refresh token is used to gain a new access_token (JWT) from Auth0.
  • The new access_token (JWT) is then passed back to the mobile app.

Any thoughts or suggestions on the process would be much appreciated.

2

For obvious reasons you’re unlikely to find someone that will certify a solution over the Internet; that situation is even worse in my case, because I’m replying as part of the Auth0 support team so it would be totally impossible to completely validate a solution as that goes beyond my job description. I can, however, discuss general recommendations and an additional point of view.

For the native mobile apps you seem to be introducing a middle-man that does not do any additional logic, it just translates requests from the application to an authorization server (Auth0). So, for this situation, this is mostly the same as using the resource owner password credentials (ROPC) grant directly from the mobile app. This has some considerations given the mobile application will need to process user credentials directly, however, usage of ROPC in mobile applications is something acceptable if you have very constrained requirements in the UX. In conclusion, your solution with an additional proxy is mostly the same as long as communication to the proxy is as secure as the communication that would occur if the authorization server was used directly.

For the SPA scenario you’re doing something much more custom and if there are sessions involved reducing that client application to a SPA seems a bit to much. Personally, I would just treat that application as regular web application that maintains its own session. In conclusion, I would personally not choose to move the access tokens to the browser-side and would just deal with a traditional cookie-based session and a back-end that handles such type of session (that back-end could make further calls to other API’s using access tokens, but that would be an implementation detail).