5

I've been reading up on this for months and it seems like the whole thing could converge on what I'm summarizing below. I'm trying to arrive at the most ideal:

  • OAuth2
  • OpenID Connect
  • SPA / Mobile Client
  • JWT

Solution that has banking level security quality as the above component are concerned. So this is what seems to make sense.

  • Use the Authorization Code Grant without using server side sessions and cookies since this OAuth flow is more secure than the implicit flow.
  • Do not create server side sessions or cookies (Besides perhaps remember me cookies to identify whether the client has been authenticated before). This is better for scaling and overall simplicity.
  • Return a JWT / OpenID connect token to the client so that the client can use it to make API requests and for making authorization decisions within the client. (I think this is what the OAuth2 hybrid Authorization Code Grant / Implicit flow is?). Store the JWT / OpenID connect token in the clients session storage.
  • Have short lived JWT tokens and also offer up refresh token until the user logs out. The client would automatically receive refresh tokens unless it times out / the client side session expires or the user logs out. The refresh tokens would be fetched and served by the edge server that / OAuth client that the SPA / mobile app is talking to.
  • On logout (Or timeout), remove the token from browser session storage.

Is any of this crazy / does it sound reasonable? It skips over invalidating tokens, but it seems ok to do this if the tokens have very short life times and the client can get refresh tokens. I'd like to implement this using Spring-Boot / Spring Security and Angular 4/5 and I'm wondering if I missed anything obvious or perhaps there is an even simpler approach that does not sacrifice/lower security?

Also do you think this would pass "Banking" level security standards check?

Community
  • 1
  • 1
Ole
  • 41,793
  • 59
  • 191
  • 359
  • First read: https://stackoverflow.com/help/how-to-ask But I would guess use: OpenID Connect with an Certified Library: https://openid.net/certification/ Follow Best Practices for OpenID Connect https://openid.net/specs/openid-connect-basic-1_0.html https://openid.net/specs/openid-connect-implicit-1_0.html – jwilleke Oct 07 '17 at 11:05
  • Yeah I know what you mean by the "How to ask" tip - I feels like I'm "stepping outside the boxes" a bit with the above approach, so just checking to see whether anyone sees anything crazy that perhaps I should be considering ... – Ole Oct 07 '17 at 18:29

1 Answers1

2

Update : Implicit flow is no longer recommended. It is advicec to use authorization code flow with PKCE even for SPAs

Original answer

Few things to clear out,

1. You have to use implicit flow for browser based applications

This is becuase such applications cannot be made confidential and cannot protect a refresh token it recieves. OAuth2.0 RFC too explain about the flow.

Also, according to OAuth2.0 Refresh token definition, Refresh tokens are sort of a credential.

Refresh tokens are credentials used to obtain access tokens

Section 10.4 of RFC6749 explains more about refresh token security, thus explaining the need to use implicit flow for broweser based applications.

2. Implicit flow does not send a refresh token

From OAuth2.0 RFC

When using the implicit grant type flow, a refresh token is not returned, which requires repeating the authorization process once the access token expires.

So when the access token expires, you have to go through the same flow to take a new token set

3. ID tokens usage

Must vlaidate according to specficiation. If the id token is valid, user is authenticated

4. API calls

Two options, either use access token or user ID token.

Usage of access token to communicate with API endpoints is common. It is the intended usage of the access token. From the API endpoint, access token can be vlaidated using introspection endpoint (if the identity provider support one).

But ID token JWT can also be used as a bearer token. For this to be done, API endpoint will need a warapper to validate the ID token. This blog/document contains some good points to consider.

Community
  • 1
  • 1
Kavindu Dodanduwa
  • 12,193
  • 3
  • 33
  • 46
  • 1
    wrt. 1.: technically you can also use the Authorization Code grant, but only with a public Client, so no client_secret – Hans Z. Oct 09 '17 at 08:09
  • Thank you - great answer - and it illustrates one of the reasons I asked the question. I'd like to use the Authorization Code grant flow, but with refresh tokens, no sessions (No other session tokens/cookies), and while also returning the jwt token or refresh token to the client / SPA for resource server authentication. This type of scenario is outside of the standard / blue print for OAuth2, but I think it can be implemented by tweaking out the authorization server a bit. – Ole Oct 09 '17 at 15:28
  • Perhaps a better more focused question is "How to use the Authorization Code Grant flow for browser based application without server sessions ..." – Ole Oct 09 '17 at 15:31
  • @Ole As from your explanantion, I tihnk you need to decide on the choice of your client (client for identity provider). For example, right now you are choosing it as the browser application. But you can potentially change the scenario to make your browser (sort of an) end user, and use a wrapper in your resource server to act as the client. Thus the wrapper completes the Authentication flow and recieve tokens, and authneticate the browser application based on session (if it is okay) or based on token. A bit of a complex, but doable thing – Kavindu Dodanduwa Oct 10 '17 at 02:43
  • 1
    I understand what you mean, although that requires (I presume) server side sessions, which is what I'm trying to avoid. I'd like the security benefits of the Authorization Grant Flow, without server side sessions. – Ole Oct 10 '17 at 10:53
  • 1
    IIUC after the Authorization Grant Flow completes the edge server / client application (Not the browser) creates a session identifier (JSESSIONID in Java) normally. If that identifier is replaced with a JWT / OpenID connect token and that is sent to the client then we benefit from the increased Authorization Grant Flow security and refresh tokens as needed. The edge server would manage this. – Ole Oct 10 '17 at 10:53
  • 1
    So when a token reaches the edge server, the edge server could verify the signature and forward it to the resource servers, or if the token has reached the expiration window it could send it to the authorization server and ask for a refresh token. – Ole Oct 10 '17 at 11:28
  • @Ole yes, the solution is viable. But the emphasis should give on protecting the tokens – Kavindu Dodanduwa Oct 11 '17 at 04:53