In a enterprise distributed system, a user of a web portal can sign into one site, be redirected to a federation provider. Once they log in with, for example, a facebook account, that user is federated (single-sign-on) with each service that exists in the enterprise that trusts the same federation provider for authentication.

My question is this; How can API users of the same system benefit from the same luxury (single sign on) ? As far as I understand it, API calls should be stateless, thus each request should require separate authentication.

If each of the distributed API's, when called by a client, need to make a call to the federation provider, get authenticated, pass claims back to the API, then process the clients request, it seems a little network chatty to me.

To clarify, an example scenario for an API client might be :

  1. Create a customer (customer API)
  2. Create a user for that customer (user API)
  3. Place an order (order API)
  4. View billing statement (billing API)
  5. View customer report (report API)

Like I say, it seems a little chatty for each API to talk to the federation provider on each request.


In general:

  • User logs into some authentication system.
  • Authentication system provides a token that effectively says "Authentication System X asserts that you are Bob, until 3:00 PM 8/31/2015 UTC".
  • User then passes that token as metadata (header, some data envelope) to the various APIs.
  • The various APIs look at it and decide if they trust Authentication System X. If they do, they let Bob in, since only Bob could've had the authorization credentials (password, fingerprint, retina, etc) to get this token.

The nitty gritty details of setting all that up will vary depending on what Authentication System, what sort of Token, and what API libraries you're using. Though if you're doing something beyond basic google/facebook integration, it's likely to be agonizing.


Can't use OAuth2 protocol for that. Having authenticated user once, system issues access token to it. This token will be sent with an each request.

Oauth2 has several flows. They are primarily for end-user, but for server-to-server interaction you can use two-legged OAuth like Google Data API uses now.


Depending on how you will implement your application you can create a resource/API to generate a token as @Telastyn said (or you can use an authorization server - a different application to generate and validate these tokens) and pass it as a header field (usually people use the Authorization header) and your API check it's validity (in the same application or in the authorization application).

Your Answer

