2

We're looking to implement web (external user) SSO and an API gateway to support web apps and mobile apps, and potentially 3rd party apps and even B2B scenarios.

My thought is to have the SSO gateway handle user-level access to websites and APIs, authenticating end users using OAuth or OpenID Connect.

Sitting behind this, for any API URLs, is the API gateway. This is intended to handle the client-/application-level authentication using something like a client ID and secret.

SSO/API gateway

The idea would be that the user would log into a website or mobile app, and then if/when that app needed to call an API it would need to send its own credentials (client credentials flow) as well as a bearer token proving who the user is as well (resource owner password flow).

The client credentials are less about security and more about coarse-grained access to API functions, giving visibility of API usage, traffic shaping, SLAs etc., but the user identity is needed to enforce data-level authorisation downstream.

Most API gateways I've looked at appear to only support a single level of authentication, e.g. we're looking at Apigee at the moment that can use OAuth to authentication to handle either a user or an app, but it's not obvious how to do both at once.

Is there any way to get the SSO gateway's user bearer token to play nicely with the API gateway's client bearer token or credentials, preferably in a fairly standards-based way? Or do we just have to hack it so that one comes through in the auth header and the other in the payload? Or is there a way to have a combined approach (e.g. hybrid bearer token) that can serve both purposes at once?

I'm kind of surprised that with all the work going on in identity management (OAuth2, OpenID Connect, UMA, etc.) nobody is looking at a way of handling simultaneously the multiple levels of authentication - user, client, device, etc.

ChrisC
  • 2,393
  • 2
  • 18
  • 24
  • A little curious why you think you can't do both at the same time out of the box? – brandonscript Jul 21 '15 at 01:30
  • For client level I would request an access token from Apigee's oauth accesstoken URL and then pass it in the HTTP Authorization header. However the SSO gateway also does a similar thing with the user (resource owner) login and I believe also tries to pass it through in the Authorization header. Obviously they can't both do this. I might be able to wrangle the SSO gateway to put the user bearer token somewhere else (payload or custom header) but it all seems very inelegant, and I was wondering whether there are any approaches for combining both concepts into a single user+client auth token. – ChrisC Jul 21 '15 at 05:20
  • Ultimately it would be nice to have a unified token that contained proof of user, client and device identity in one neat package. Maybe one day... – ChrisC Jul 21 '15 at 05:21
  • You could pass an apikey as a query param (like Apigee's oauth uses out of the box) and then add the auth token headers on top of it. – brandonscript Jul 21 '15 at 05:22
  • Yes I could, but the downside would of course be losing the ability to use OAuth for the clients - I guess something I can live without. Apigee seems to only support OAuth bearer tokens passed in the HTTP headers. – ChrisC Jul 22 '15 at 05:36
  • You can customize it however you like - no need to drop OAuth? – brandonscript Jul 22 '15 at 05:37
  • I'm having trouble finding any reference to how to send an OAuth bearer token using anything but the HTTP Authorization header... [Apigee docs](http://apigee.com/docs/api-services/content/sending-access-token). There might be scope for putting the user (SSO) bearer token elsewhere but I haven't been able to confirm that yet. – ChrisC Jul 22 '15 at 06:09

1 Answers1

1

Unfortunately I don't have enough reputation points to comment on the previous post, so I'll add my two cents here. Full disclosure: I work for Apigee.

http://apigee.com/docs/api-services/content/oauthv2-policy#accesstokenelement explains how to give the access token to the Apigee OAuthV2 policy in a place other than the Authorization header. If you've stored the SSO bearer token as an attribute of the Apigee OAuth token then once the Apigee token is validated you'll automatically get the SSO bearer token as a flow variable and can use it as needed.

For example, if you send the token as a "token" query parameter on the request you can code the following in the OAuthV2 policy

request.queryparam.token

and the policy will pull it from that query parameter.

Chris von See
  • 56
  • 2
  • Thanks Chris, sounds like this is the best way to go. I haven't been able to find reference to any initiatives to support a multi-identity authentication / authorisation scheme unfortunately (e.g. combining user, client, device) so it's good to uncover at least how multiple OAuth tokens can coexist, even if it requires non-standard ways of passing them through. – ChrisC Sep 02 '15 at 22:52