When Kerberos was chosen to be AD’s authentication protocol in the mid- to late-1990s, the World Wide Web was a shadow of what the Internet offers today. Although the Kerberos ticket contained an encrypted password hash that could be attacked, there wasn’t any substantial requirement to provide support outside the highly protected corporate firewall.
The rise of cloud services is changing many aspects of our lives, and these services don’t support external authentication via Kerberos because of that password vulnerability. If a web service uses standards, it handles claims-based authentication using SAML 2.0 or, increasingly, OAuth 2.0 and OpenID Connect. Microsoft’s own Azure Active Directory doesn’t use Kerberos; it supports SAML and OAuth 2.0 as its authentication protocols.
OAuth in details
OAuth is an authorization method to provide access to resources over the HTTP protocol.
OAuth2 can be used for authorization of various apps (server/browser/mobile)and desktop applications or manual user access.
The general way it works is allowing an application to have an access token (which represents a user’s permission for the client to access their data) which it can use to authenticate a request to an API endpoint.
A sample OAuth flow: Facebook
There are two versions of OAuth authorization OAuth 1 (using HMAC-SHA signature strings) and OAuth 2 (using tokens over HTTPS).
Note: SoapUI currently only offers Oauth2 authorization.
OAuth 2 terms
Conceptually, OAuth2 haas a few components interacting: The resource server (the API server) contains the resources to be accessed. Access tokens are provided by the authorization server (which can be the same as the API server). The tokens are provided by the resource owner (the user) when accessing the resources. Similarly, an application using the credentials, and the API is called client.
The token Endpoint is used by clients to get an access token (and optionally refresh token) from the authorization server.
Note: When using implicit grant, this endpoint is not used. Instead the access token is sent from the authorization endpoint directly.
The two token types involved in OAuth 2 authentication are Access Token and Refresh Token.
The access token is used to for authentication and authorization to get access to the resources from the resource server.
The refresh token normally is sent together with the access token.
The refresh token is used to get a new access token, when the old one expires. Instead of the normal grant type, the client provides the refresh token, and receives a new access token.
Using refresh tokens allows for having a short expiration time for access token to the resource server, and a long expiration time for access to the authorization server.
Access tokens have a type, which defines how they are constructed.
The bearer tokens use HTTPS security, and the request is not signed or encrypted. Possession of the bearer token is considered authentication.
More secure than bearer tokens, MAC tokens are similar to signatures, in that they provide a way to have (partial) cryptographic verification of the request.
Methods to get access tokens from the authorization server are called grants. The same method used to request a token is also used by the resource server to validate a token.
The four basic grant types are Authorization Code, Implicit, Resource Owner Credentials and Client Credentials.
Note: SoapUI currently only offers the grant types Code Grant and Implicit.
With authorization_code grant, the resource owner allows access. An authorization code is then sent to the client via browser redirect, and the authorization code is used in the background to get an access token. Optionally, a refresh token is also sent.
The implicit grant is similar to authorization code, but instead of using the code as an intermediary, the access token is sent directly through a browser redirect.
Resource Owner Credentials
The password/Resource Owner Credentials grant takes the uses the resource owner password to obtain the access token. Optionally, a refresh token is also sent. The password is then discarded.
In client_credentials grant mode, the client’s credentials are used instead of the resource owner’s. The access token is associated either with the client itself, or delegated authorization from a resource owner.
Grant Type Extensions
OAuth has a mechanism for extending grant types as a bridge to other authorization frameworks, or for specialized clients.
Extension grants are used by clients through an absolute URI together with a grant_type parameter and by adding any additional parameters necessary to the end point.
In OAuth 2, the scope is a way to restrict access to specified areas. A common way of handling it is with a comma-separated or space-delimited list of strings, where each string indicates an areas of access.