OAuth2 is the new Code Exchange project that allows you to authenticate on a web based service provider like Google, Facebook, Microsoft and Foursquare using the OAuth 2.0 protocol.
OAuth 2.0 is the next evolution of the OAuth protocol and is not backward compatible with OAuth 1.0. OAuth 2.0 focuses on client developer simplicity while providing specific authorization flows for web applications, desktop applications, mobile phones, and living room devices. (Wikipedia)
Most of popular on line services like Google, Facebook and Microsoft are already providing access to their cloud using this protocol.
OAuth vs. OAuth 2.0
OAuth 1.0 was largely based on two existing proprietary protocols: Flickr’s API Auth and Google’s AuthSub.
OAuth 2.0 is not a new version of OAuth; it is a different approach that would solve all the limitation of OAuth 1.0.
The success of OAuth 1.0 (especially with the explosion of Cloud services) and the experiences across these years lead the community to rethink and improve the protocol.
First big difference is the authentication flow; OAuth 1.0 is based on unique flow for web-based applications, desktop clients, and mobile or limited devices. This approach is basically well designed for web application but it is a compromise for others.
On other hands OAuth 2.0 differentiate the authentication in different flows:
- User-Agent Flow – for clients running inside a user-agent (typically a web browser).
- Web Server Flow – for clients that are part of a web server application, accessible via HTTP requests. This is a simpler version of the flow provided by OAuth 1.0.
- Device Flow – suitable for clients executing on limited devices, but where the end-user has separate access to a browser on another computer or device.
- Username and Password Flow – used in cases where the user trusts the client to handle its credentials but it is still undesirable for the client to store the user’s username and password. This flow is only suitable when there is a high degree of trust between the user and the client.
- Client Credentials Flow – the client uses its credentials to obtain an access token. This flow supports what is known as the 2-legged scenario.
- Assertion Flow – the client presents an assertion such as a SAML assertion to the authorization server in exchange for an access token.
Moreover authentication in OAuth 2.0 does not require managing different tokens (e.g. the request token) during the process; this approach enhances the user experience.
OAuth 1.0 authentication flow
- The flow starts with the application asking for a request token. The purpose of the request token is to obtain user approval and it can only be used to obtain an access token. In OAuth 1.0, the consumer callback URL is passed to the provider when asking for a request token.
- The service provider issues a request token to the consumer.
- The application redirects the user to the provider's authorization page, passing the request token as a parameter. In OAuth 1.0, the callback URL is also passed as a parameter in this step.
- The service provider prompts the user to authorize the consumer application and the user agrees.
- The service provider redirects the user's browser back to the application (via the callback URL). In OAuth 1.0, this redirect includes a verifier code as a parameter. At this point, the request token is authorized.
- The application exchanges the authorized request token (including the verifier in OAuth 1.0) for an access token.
- The service provider issues an access token to the consumer. The "dance" is now complete.
- The application uses the access token to establish a connection between the local user account and the external provider account. With the connection established, the application can now obtain a reference to the Service API and invoke the provider on behalf of the user.
OAuth 2.0 authentication Web Server flow
- The flow starts by the application redirecting the user to the provider's authorization URL. Here the provider displays a web page asking the user if he or she wishes to grant the application access to read and update their data.
- The user agrees to grant the application access.
- The service provider redirects the user back to the application (via the redirect URI), passing an authorization code as a parameter.
- The application exchanges the authorization code for an access grant.
- The service provider issues the access grant to the application. The grant includes an access token and a refresh token. One receipt of these tokens, the "OAuth dance" is complete.
- The application uses the AccessGrant to establish a connection between the local user account and the external provider account. With the connection established, the application can now obtain a reference to the Service API and invoke the provider on behalf of the user.
Other to great enhancements in OAuth 2.0 protocol are:
- cryptography-freeoption for authentication which is based on existing cookie authentication architecture. Instead of sending signed requests using HMAC and token secrets, the token itself is used as a secret sent over HTTPS. This allows making API calls using cURL and other simple scripting tools without having to canonicalize the request and sign it.
- Short-lived tokens with Long-lived authorizations Instead of issuing a long lasting token (typically good for a year or unlimited lifetime), the server can issues a short-lived access token and a long lived refresh token. This allows client to obtain a new access token without having to involve the user again, but keeps access tokens limited.
More detailed info and minor changes are available on internet.
Installation and configuration
OAuth2 comes as a nugget file and can be imported into your system using SAPLink. More information on install procedure and configuration will be available in the next days on Code Exchange GITHub.
OAuth2 requires ABAP JSON Document Classcreated by Uwe Fetzer to be installed into your system.
The OAuth2 team
The project was made possible thanks to the important contribution of Techedge Labs team, particularly Giacomo Morittu andAlessandro Iannacci.
References
- SAP Managed Tags:
2 Comments
| User | Count |
|---|---|
| 5 | |
| 3 | |
| 3 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |
