Whilst comparing different authentication schemes such as HTTP Basic Authentication vs. HTTP Digest Access Authentication, one-way SSL vs. two-way SSL, SAML vs. WSS or OAuth 1.0 vs. OAuth 2.0 one notices that they all address similar problems when it comes to apply signatures in order to achieve the known AAA principles. However, the way and where digital signatures are applied, especially to new authentication protocols such as OAuth, can open new and interesting scenarios to secure API.
The numerous feedback received from the “Authentication vs. Authorization with OAuth” blog (Knupfer Rainer, Bricalli Cristina. 2016) shows that we have maybe indeed put too many irons in the fire. We introduced different OAuth specification versions, we mentioned Bearer Tokens and signatures, briefly evaluated the pro and cons of PKI vs. shared key and designed an overall architecture of a self-registering portal. That’s a lot! It was to our great satisfaction that the requirement of strong authentication for confidential exposed information has been understood. However, we feel the need to go one step further to clarify different aspects regarding signatures and token type in the context of OAuth that often lead to confusion.
Technical architects and software engineers often need to deal with many details, different types of architectures, technical specifications and buzzwords and so it may happen that “subtle” differences such as signing the request and tokens do not emerge straight away. While the first secures the communication between two parties, the signed tokens are used to protect token integrity and are necessary to establish a trusted relationship between the authorization server and protected resource.
(Source: Understanding Trust-Direction. 2016)
Referring to the previously written blog post, the OAuth 1.0a 2-legged usage falls in the category of protecting the request. As a “collateral” effect, we achieved strong authentication. However, apart from the fact that OAuth specification was originally developed to protect insecure communication, the stated objective was to create an authorization delegation protocol (hueniverse. 2016). In this delegation process, the acquired token for accessing the protected resource plays the most important aspect.
In the token context used with the OAuth2.0 specification, we encounter the Bearer Token Profile (RFC 6750, 2016) and the Message Authentication Code (MAC) Token Profile (OAuth 2.0 Message Authentication Code (MAC) Tokens. 2016). Comparing Bearer Tokens and MAC Tokens is like comparing cash with credit cards. While the former can be used by anyone without legitimation, the MAC Tokens must be first signed in order to be used and validated thereafter. In fact, the MAC Tokens specification defines how clients must sign the OAuth 2.0 request required by the service provider. As a matter of fact, the Bearer Token must be used in a trusted environment with secure HTTPS communication channel. In contrast, MAC Tokens can be used in different scenarios such as: Integrity protection over insecure channels, Point-to-Point Encryption (P2PE) or End-to-End Encryption (E2EE) over multiple hops. Similar to the signed request, a signed token has the benefit of offering an authentication and non-repudiation mechanism.
The idea behind a MAC is to produce a message that is impossible to create without the secret key. The HMAC integrates a hashed message and the key using the HMAC-SHA1 or HMAC-SHA256 algorithm (Krawczyk et.Al., 1997) so that the receiver can check the integrity and authenticity.
Message authentication code (Source: Wikipedia. 2016)
The good thing about this method is that it’s not necessary to have a complex PKI infrastructure in place or deal with various aspects of the X509 certificates such as the certificate authority and chain of trust. As with any symmetric key encryption solution, the parties need to deal with key distribution and protection of secret keys. OAuth 2.0 is mainly a 3-legged protocol that accesses the protected resource with the previously exchanged Authorization Grant for an Access Token and so the token is used to calculate the MAC.
In order to validate the request, the OAuth 2.0 MAC Token Profile defines the mac_key, a session key used as the key to sign and the encrypted shared key embedded in the access_token. Of course, this profile uses nonce and timestamp in order to detect and mitigate replay attacks but this is the approximate way this profile exchanges the secret over the wire.
A bit confused after reading both blog posts? Is it not controversial to advocate the OAuth 1.0a 2-legged schema with PKI infrastructure in one discussion and then go on to “promote” the OAuth 2.0 3-legged schema with symmetric encryption? A consultant would answer, yes but … it depends. Indeed, securing API is not a trivial matter that can be solved without raising doubts. The best approach would be to technically compare the two specifications and find the right usages, but this is not up for discussion here. For the sake of simplicity, we can assert that OAuth 1.0a is definitively a secure and tested signature-based protocol successfully used in enterprise environments. Even if OAuth 2.0 seems to be an evolution, in reality it is a different approach security wise. At present, enterprise environments with security gateways in place still tend to adopt OAuth 1.0a while OAuth 2.0 is mainly used in social networks where more moderate security is required. The MAC Token profile is more sophisticated to implement for the client and the resource server. Furthermore, the proposal has not yet been finalized and verisimilar it is not widely adopted by the IT-industry.
References
hueniverse. 2016. Beginner’s Guide to OAuth – Part III : Security Architecture | hueniverse. [ONLINE] Available at: https://hueniverse.com/2008/10/03/beginners-guide-to-oauth-part-iii-security-architecture/. [Accessed 13 September 2016].
RFC 6750 - The OAuth 2.0 Authorization Framework: Bearer Token Usage. 2016. RFC 6750 - The OAuth 2.0 Authorization Framework: Bearer Token Usage. [ONLINE] Available at: https://tools.ietf.org/html/rfc6750. [Accessed 13 September 2016].
draft-ietf-oauth-v2-http-mac-05 - OAuth 2.0 Message Authentication Code (MAC) Tokens. 2016. draft-ietf-oauth-v2-http-mac-05 - OAuth 2.0 Message Authentication Code (MAC) Tokens. [ONLINE] Available at: https://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-05. [Accessed 13 September 2016].
Krawczyk, Bellare, Canetti. 1997. HMAC: Keyed-Hashing for Message Authentication. [ONLINE] Available at: https://www.ietf.org/rfc/rfc2104.txt. [Accessed 14 September 2016].
Knupfer Rainer, Bricalli Cristina. 2016. Authentication vs. Authorization with OAuth, Does It Really Matter?, Available here (Accessed: 16th September 2016).
Understanding Trust Direction. 2016. Understanding Trust Direction. [ONLINE] Available at: https://technet.microsoft.com/en-us/library/cc731404(v=ws.11).aspx. [Accessed 27 September 2016].
Wikipedia. 2016. Message authentication code - Wikipedia, the free encyclopedia. [ONLINE] Available at: https://en.wikipedia.org/wiki/Message_authentication_code. [Accessed 27 September 2016].