RESTful API Authentication and SSO with OAuth2 / OIDC

user_489560 0
Viewed 898

Imagine the following common scenario. I have a single-page web application (SPA) that receives all its data using RESTful APIs I wrote on the backend.

These APIs are available to third-parties as well, exactly as is. My single-page app is just another among millions using the APIs. A session is maintained in the background for the benefit of authentication and caching. The session persists through a cookie with a session-id.

To use the APIs, a user must authenticate. I need to support the big SSO method (OIDC/OAUTH2) for my application. Obviously, my APIs need to be usable by an integration software such as Dell Boomi or plain ol' SSIS.

Now... let's talk authentication and authorization flow. After days of reading everything I could on OAuth2 and OpenID, I imagine the following workflow. myapp.com is configured to SSO through Facebook (arbitrary):

  1. [Web Browser]: GET /customer/1 > [API Server]
  2. [API Server]: Dunno you, chump. 302 redirect here, plz. > [Browser] https://www.facebook.com/oauth/login?client_id=abcdef&state=12345
  3. [Browser]: Username: lintlicker, password: iluvcats123 > [Facebook]
  4. [Facebook]: Yup, you're someone. 302 redirect here, plz. > [Browser] https://www.myapp.com/oauth/imback?code=a1b2c3d&state=12345
  5. [Web Browser]: json of the stuff from the url > [API Server]
  6. [API Server]: Here's a code and client-id and client-secret > [Facebook]
  7. [Facebook]: Here's a token to run Facebook APIs for this user................................

But, wait. I don't want to run Facebook APIs. I just want to authenticate using Facebook, and then run my app's APIs... Already you can see I misunderstood OAuth versus OIDC.

Okay, so then Facebook is the authenticator using OpenID. But what about OAuth for external use of my APIs?

Should my API server basically be forwarding the OAuth request from the browser/ requestor on to whoever the identity provider is? And then instead of a session-id in a cookie, I send back an access token that expires in, e.g., an hour, as well as a refresh token? Then the browser is responsible for re-upping the token?

Does that mean the browser or requestor has a client secret? Obviously not. So then does that mean I have to use/ support the depreciated implicit grant method?

What's a good architecture here?

oauth-2.0 openid-connect restful-authentication oauth rest
1 Answers

By using SSO your goal seems to provide social login behaviour. For this you do not need to rely on token issued by Facebook. What you can do is obtain user data from ID Token or by invoking user information exposing API of the identity provider (ex:- Facebook) and store them in one of your back-end. From there onward, you have the ability to maintain authenticated status either through your own token or a session.

About other integrations (API to API), for those integrations your back-end can issue tokens upon successful completion of an OAuth flow (ex:- client credential grant). And if such integration comes with an third party token (ex:- Facebook), then your back-end can allow a token exchange (plus user on-boarding, registration if required).

Downside of above approach is the requirement of your back-end to handle those requests. I would suggest to embed a lightweight identity provider if possible. This should give everything out of the box.!

user_31970550
Related