Hi
I think Your question is a very general one. You didn't mention anything about Apigee Edge. So let's talk about OAuth 2.0, and we will take it from the top. Pardon me if this is not what you were asking about.
OAuth 2.0 is a framework specified in
IETF RFC 6749 that describes how apps can obtain limited access to HTTP (usually RESTful) services. The main method for doing so involves
- apps request tokens
- the token issuer generates a token and delivers it to the app
- the app then repeatedly sends back that token in requests for service
If you have ever ridden an old-fashioned underground or subway, you may have used a token to get access to the transit system. Most transit systems have moved to stored-value cards, so this analogy is somewhat dated now. A subway token isn't worth anything, unless the possessor presents it to the subway turnstile. In that case the token is good for access to the subway or underground system. Anyone that has the token can use it to get access; in that sense the holder or "bearer" of the token is granted the access. If you lose a subway token, and someone else finds it, then the token is still good for access to the subway, even though a different person holds it.
OAuth tokens work similarly - an OAuth bearer token is just a thing that grants access to a system. OAuth tokens are a little more complicated, in that they can
- confer limited access rights (aka "scope")
- expire
- be revoked
But basically the subway token analogy holds pretty well.
So how can you build an app and a service, such that the service grants access based on a generated OAuth token? Here's the idea of how it should work:
- The app requests a token from a token-issuance service. The app may need to present various credentials. First, app credentials, which identify the app itself, including the identity of the developer. Optionally, user credentials, like a user name and password. Or even something more complex involving 2-factor authentication. The app may also request a specific, limited scope.
- The token-issuance service validates the credentials of the app and optionally the user; the token-issuance service may also validate the requested scope. Not all users will be allowed to request all scopes. For example, some users may be granted read scope, while others may be able to request read and write scope.
- The token-issuance service generates an opaque token, and stores it along with all the other metadata associated to the token: app identity, user identity (optionally), scope, expiry, and maybe some other custom attributes.
-
The token issuance service then returns the token, and optionally *some* of the metadata I just described, to the calling app. For example the token issuance service may respond with:
{
"access_token" : "ABCDEFGHIJKL",
"expiry" : 1800,
"scope" : "read"
}
...to indicate the returned token will expire in 1800 seconds, and that the scope is "read".
- Subsequently, the app can present that token back to a service when requesting service. The OAuth spec recommends using the Authorization HTTP header for this purpose. The header would look like this in an HTTP request:
Authorization: Bearer ABCDEFGHIJKL
The service then validates the token - checking its expiry and scope - before performing the requested operation. Depending on how the system is designed, the service may need to explicitly contact (call out to) the token-issuance service to validate the token.
Where does Apigee Edge fit in?
Well as you know, there are many different frameworks now that allow developers to build services very easily. Whether you are coding in Java, or Go, or nodejs, or PHP or Python or C# or ..... any language, it's pretty straightforward to build RESTful services.
The challenge comes in when you want to do things like:
- build in scalable token verification for those services
- allow management of registered apps - management meaning creation of apps, update of apps, management of app credentials, revoking apps, measuring or throttling requests by specific apps, and so on
Apigee Edge can act as a proxy that performs the token verification at runtime for you. Apigee Edge can also act as the token-issuance service, and usually does; it can validate client credentials, validate user credentials, participate in a 3-legged OAuth flow, or participate in an OpenID Connect flow.
With Apigee, You don't have to write code in order to add high-scale, reliable OAuth protection to your existing APIs.
Apigee Edge does more than OAuth of course. This is just one tool in the toolbox.
Maybe you want to know specifically how to do this OAuth stuff in Apigee Edge?
Well we have a number of assets to help, including
- documentation - link
- tutorials - link
- screencasts - link
- hands on guided exercises - link.
If you have further questions, please let me know.
LinkedIn
Twitter
