- Simplicity: Client developers don't need to do any cryptography or use a library to call OAuth 2.0 protected resources. The token can be passed in the HTTP headers or as a URL parameter. While HTTP headers are preferred, a URL parameter is simpler and allows API exploration with a browser.
- Token choice: implementers can use existing tokens that they already generate or consume. There are extension points so that the client can sign the token instead of it being a bearer token.
- Separation of roles: if the token is self-contained, then the resource can verify the token independently of the authorization server. Resources don't have to call back to the authorization server to verify the token on each call, enabling higher performance and separation of security contexts.
Internet entrepreneur, digital identity expert, gadget geek, foodie and husband.