1

I have a custom OAuth 2.0 authentication server deployed alongside my secured API. I also have a single page application delivered as static content by an nginx deployment. I'm now confronted with the issue of how to authenticate users of this SPA without an active backend through which to proxy a password grant -- I obviously cannot embed the client secret in the SPA.

What solutions exist for such an issue?

I have discovered that the resource owner password credentials grant may be just what I'm looking for. By using this, I would be able to send username and password credentials directly from my trusted SPA using an established client ID. If I restrict this grant to only be valid for this particular client and validate the origin of the request, I can see this being a reasonable compromise.

My question then becomes, how do I create this client and the requisite associated user? Does that not imply that there is some special user account in my system with this associated privileged client? OAuth 2.0 seems to imply that clients must be associated with a user of some kind. Do I seed these special user and client objects when my application is deployed? Is that secure?

Improve this question
4
  • Have you checked the implicit flow? That's the one usually used for SPAs. Commented Apr 7, 2017 at 5:57
  • @JánHalaša, I have yes. This was my original assumption but I believe this still requires a redirection for the end user, is that not correct? Commented Apr 7, 2017 at 17:18
  • Yes, first you forward your user to the OAuth2 server and then it gets back to the redirectUrl you provide. You get an access token in the hash part of the redirect URL. Is there a problem with the redirect? Commented Apr 8, 2017 at 10:07
  • @JánHalaša, no I suppose there isn't the more I think about it. My main confusion is more how to deploy these two applications independently while making sure the client side is constantly aware of what its client ID should be. Should I just be seeding my authorization server with a pre-established client that my SPA will use? Commented Apr 11, 2017 at 19:34

1 Answer 1

Reset to default
1

I think the implicit flow could be used just fine.

  1. User is redirected from the SPA to the OAuth2 server
  2. User authenticity is verified
  3. User is redirected back to the SPA along with tokens

For the server-side API, you need to decide whether you want to use access tokens or ID tokens (OpenID Connect - OAuth2 extension).

If user's permissions for the API are stored at the OAuth2 server, the SPA may ask a user for some of the permission that will be included in the access token. This is a permission delegation and it can be handy if there are more application each requiring different permissions.

If the OAuth2 server doesn't hold the permissions and the API manages them itself, it's probably more suitable to use ID tokens, because they represent identity of the caller and can be verified without accessing the OAuth2 server on every access.

The API probably doesn't need to have its client_id, since it just accepts tokens - it doesn't request them - it checks that access tokens contain permissions for actions users invoke or validates ID tokens.

The SPA needs to have its client_id with registered redirect_uri-s. No client secret needed, since SPA-s cannot keep them safe. It has to be deployed using HTTPS to secure the transferred tokens.

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.