05. December 2016

MAC Token Profile: the Never-Ending Battle over Signatures

MAC Token Profile: the Never-Ending Battle over Signatures<br/>

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.


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].

Rainer Knupfer
Rainer Knupfer

Rainer Knupfer is a Lead Engineer at ti&m, graduated in Computer Science and IT-Information Security and has accumulated the right mix between education, consulting experiences and hands-on jobs. He's particularly interested in different aspects of technical security applied to software integration and development in different domains such as digital payment, security authentication design, regulatory compliance and omni-channel applications.

Ähnliche Artikel

Handling the Communication Channel Shift to Social Media
How to Mine Gold: Handling the Communication Channel Shift to Social Media

Data being the gold of the 21st century is a given fact by now. Still, most companies do not have a strategy on how to handle social media data, even though it has become the main channel of client communication. To tackle this problem, we recently carried out a ti&m garage with a major Swiss bank.

find more information
Why Podman is worth a look

When it comes to managing containers, Docker is often the first choice. But Podman can also be an alternative. In this blog post, we take a closer look at the differences between the two tools and the points you need to consider if you plan to use Podman.

find more information
I do not love you
I do not love you

For most readers, the title above probably has a strong negative connotation. What if instead of "you", the name of a company was used? The statement still has the same negative connotation, but an opinion of a customer regarding a company might be even more sensitive – at least from a sales point of view. Such public reviews constitute important sources of information for both prospective clients and companies alike. How can one identify, ideally in an automated way, such polarised opinions in the vastness of today’s cyberspace?

find more information
Der ideale Workload für die Cloud – Buildprozesse mit Spot-Instanzen

Eine der ersten Fragen, die sich im Cloud Kontext stellt, ist: Welche Workloads eignen sich für den ersten Schritt in die Cloud? Lesen Sie im Folgenden, weshalb Build- und Test-Prozesse für Software-Artefakte besonders geeignet sind und was es basierend auf den Erfahrungen aus unserem Projekt mit der BANK-now zu beachten gilt.

find more information
Eine neue Möglichkeit der Art Direction bei responsiven Bildern
Eine neue Möglichkeit der Art Direction bei responsiven Bildern

Das Jahr 2015 markiert ein Meilenstein in der digitalen Medienlandschaft. Zum ersten Mal verwendeten mehr Leute das Internet über mobile Geräte als über Desktop-Browser. Die Webseitenbetreiber haben deshalb ihre Webseiten responsive gestaltet. Je nach Gerät und Bildschirmgrösse wird das Layout der Seite anders dargestellt, so dass der Inhalt immer optimal sichtbar ist.

find more information