Browser based OAuth / OpenID with persistent login

Question

We have a regular web application with cookie based auth and now we want to split frontend and backend (api) in order to have third-party public API. So our backend will be on one domain and frontend on another one.

For authorization we would like to switch for OAuth 2 with JWT. In this case our frontend app will have to use access_token instead of cookie session and it brings a big old question:

How To Remain Logged In - The Infamous "Remember Me" Checkbox (part II from Form based authentication for websites)

From OAuth2 point of view our frontend application going to use something between Resource Owner Password Credentials Grant and Implicit Grant. It is closer to Password Credentials Grant since we still going to use usual login form and won't redirect user to another domain in order to sign in. At the same time it is closer to Implicit Grant since it's all going to be browser-only & JavaScript based when access_token will be saved in browser.

The RFC says the authorization server MUST NOT issue a refresh token if you use Implicit Grant and my question is if it's still valid in this use case when you don't really use a 3-d party OAuth but your own api? Instinctively I feel that having refresh_token in browser is a security hole and would like to confirm it with you guys, but that refresh_token seems to be the only way to have persistent login working the same way as we had with cookies.

---

**UPD** after @FlorentMorselli comment:

The OpenID specs still do not answer my question if I can use refresh_token with browser only application

• Google says they provide refresh_token only for access_type=offline
• OpenID Connect Core says you cannot use Refresh Token with Implicit Flow
• OpenID Connect Core says nothing about using refresh_token with Hybrid Flow
• There's only one place where it says something promising about refresh_token with Hybrid Flow, but nothing precise

---

UPD2 thanks to @reallifelolcat

It looks like OpenID Connect does not explicitly support Resource Owner Password Credentials Grant, meaning you have to redirect user to OpenID Connect server to perform login. Do you know if there is another way to authenticate with user credentials over OAuth 2.0?

---

I believe splitting api and frontend is getting more common these days and I'd appreciate it if you share how you solve this Persistent Login issue and if you drop it completely and force user to re-login every X weeks.

Thanks!

Answer 1

Access tokens and refresh tokens have nothing to do with login with OpenID Connect. These are only for authorizing access to user profile information and for perhaps authenticated service calls to your public API after the fact of login. Refer to the spec for the difference between the ID Token and the Access Token.

If you are going to use OpenID Connect for login, then from what you've wrote so far, it sounds like you need to host your own OpenID Provider (OP) since you want to avoid going to another domain to sign in:

we still going to use usual login form and won't redirect user to another domain in order to sign in.

If you want to be your own Identity Provider, then more power to you. This means that you going to have to deploy your own working instance of an OpenID Connect server, complete with authorization and token endpoints.

Now this is the part where your persistent login comes in. Your browser webapp will be a relying party to the OP server you now have. When a user tries to login to your browser app using OpenID Connect, they will need to authenticate themselves to your OP server. Going through the OIDC flow, your browser app will get an ID token containing an issuer/subject pair identifying the user.

It's up to you to determine how the user stays logged into your OP server, but as long as the user at least authorizes the browser app once: http://openid.net/specs/openid-connect-core-1_0.html#Consent then you can save that consent for all future requests by this browser app to login, and therefore maintain a persistent login.

You're going to have to consider how you're going to handle sessions management, but it sounds like you have some cookie thing going already so you might be able to use that (see this answer: OpenID sign in mechanism - Stay signed in ). Otherwise, you're going to end up with a situation where your browser webapp has to get a new id token all the time.

Also as Florent mentioned, there are security considerations you should consider when doing a public client thing that your browser based webapp would be. Example: https://www.rfc-editor.org/rfc/rfc6749#section-10.16