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 :
- Create a customer (customer API)
- Create a user for that customer (user API)
- Place an order (order API)
- View billing statement (billing API)
- 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.
-
Though you have to be a pretty advanced 5 year old, how about: roguelynn.com/words/explain-like-im-5-kerberosgbjbaanb– gbjbaanb2015年07月01日 14:51:57 +00:00Commented Jul 1, 2015 at 14:51
-
Why do you want this? Usually single sign on (as opposed to authorisation) is for convenience but a server doesn't mind entering a username/passwordRichard Tingle– Richard Tingle2015年07月01日 21:27:17 +00:00Commented Jul 1, 2015 at 21:27
3 Answers 3
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.
-
A lot of APIs go this route, Salesforce being one notable example. A real-world example of a NodeJS JSON web token is sitepoint.com/using-json-web-tokens-node-jsLee Harrison– Lee Harrison2015年08月31日 18:09:48 +00:00Commented Aug 31, 2015 at 18:09
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).
Explore related questions
See similar questions with these tags.