SASL Analysis, Part Four

This part will be devoted to the continuation of the analysis of technologies based on authentication in the cooperation of several parties. It will mainly include the analysis of OAUTH2 and technologies based on it. Next will be the analysis of SAML. The analysis of the technological predecessor OAUTH10A is in the previous article, which can be found at SASL Analysis, Part Three.

OAUTH2

The second generation authentication mechanism is designed to provide an extension of the possibilities in case of delegation of permissions. Again, it approaches the topic in the same way, using text or JWT tokens, transmitted by HTTPS (HTTP protocol in SSL/TLS tunnel) as a single protective layer. Other protection of user data is not available for text tokens and transmitted authentication information. Furthermore, the request for a token may not be requested by applications, but it may be another authorization domain (delegation of permissions). This way of transferring permissions between individual federated domains. This way of exchanging information is standardized, i.e. it is possible to delegate permissions to another domain. At the same time, the way of managing different domains is standardized. This is a significant operational difference compared to OAUTH1. From the security point of view, the differences are significantly smaller, the only change is the support of JWT tokens, which have built-in support for confidentiality and integrity protection.
At the beginning, the user must authenticate and register the applications. Logging takes place in a simple way, where the user enters a password, the server processes that password and compares it with the stored data (stored e.g. using the Argon2 function). In the picture, the authentication and authorization system are combined into one. In all schemes, only the term authorization server is used, because OAUTHx addresses the allocation of permissions. Authentication is done through other mechanisms. For other activities, only a login is required, based on the type of permission provided, the system selects between the following possible methods:
Authorization Code Grant: The user sends an authentication request. The authorization server provides the login using the authentication server, and then returns the URL and the Auth Code. The user forwards the specified requests to the application, which forwards the Auth Code to the authorization server. After authentication, it receives two tokens, the Access Token and the Refresh token. The Refresh token can be used to extend data access using the authorization server, the Access Token is sent to the data system (server). The Access Token allows access to the specified data.
Client Credentials Grant: The user sends an authentication request. The authorization server provides the login using the authentication server, and then returns the URL and the Access Token. The user forwards the specified requests to the application, which connects with the authorization system to ensure the authorization of data access.
Device Autorization Grant: The user sends an authentication request. The authorization server provides the login using the authentication server, and then returns the URL and the Device Code. The user forwards the specified requests to the device, which connects to the authorization system to secure the authorization of the data access.
Implicit Grant: The user sends the authentication request. The authorization server provides the authentication server login and then returns the Access Token. The user forwards the specified requests to the application, which is no longer authenticated and uses the token to secure its access to the data system (server). The specified method is used as a form of simplified solution and it is advisable to use other methods.
Resource Owner Password Grant: The user sends the authentication request. The authorization server provides the authentication server login and then returns the URL and the Device Code. The user forwards the specified requests to the application, which connects to the authorization system to secure the authorization of the data access.
The specified methods differ only in message flow and permissions for access to sensitive data (such as passwords). The token can be in text format or in JWT (JSON Web Token) format. In text mode, cryptography usage remains only at the transport channel level. In the case of JWT, the token can be digitally signed.
Processing tokens:
Pro Access Token / Bearer Token and pro Refresh Token: For JWT, HMAC-SHA256 is used for symmetric signature, for asymmetric RSA/RSASSA-PKCS1-v1_5 or ECDSA. For content encryption, AES-GCM is recommended for JWT. For token text form, encryption is not used.
For Authorization Code: cryptographic protection is not used, content is generated using a secure randomness generator. For content encryption, AES-GCM is recommended for JWT.

Channel Binding: No
Realms: Yes
Crypto-primitives: runout (RSA), current (SHA256, ECDSA)
Number of pages at authentication: 3 to 4
PQC/QRC: No
ZKP: No
Crypt interface support: Under certain conditions
Tokenization: Yes
Uniqueness: Yes
Credentials protection: TLS
Replay protection: Yes
Relay protection: Yes
Hijack protection: Yes
Forge protection: Yes
MFA support: Yes
Integrity protection: TLS, internal for JWT
Encryption type: TLS, internal for JWT

OAUTHBEARER

This is OAUTHBEARER → Server authentication against OAUTH2 server. It uses a text or JWT token (JSON Web Token). This mechanism is associated with OAuth 2.0 and provides authorization through the use of the so-called Bearer Token, otherwise Access Token. The token is a unique identifier and is presented by the client as evidence to authenticate access rights. The token is transmitted through HTTPS because it contains no internal protection against eavesdropping or misuse. Like OAUTH2 tokens, it can be in plain text or JWT format. OAUTH2 links can be summarized as:
- OAUTHBEARER was designed to work with Access Tokens generated within the OAuth 2.0 protocol.
- After authentication, it is possible to obtain the Bearer Token via OAuthorization Code Grant, Client Credentials Grant, Device Authorization Grant, Implicit Grant, or Resource Owner Password Grant through OAUTHBEARER 2.0. Once the token is available, it is used for authentication against the server providing the data.

Channel Binding: No
Realms: Yes
Crypto-primitives: Exit (RSA), current (SHA256, ECDSA)
Number of pages at authentication: 3
PQC/QRC: No
ZKP: No
Crypt interface support: Under certain conditions
Tokenization: Yes
Uniqueness: Yes
Credentials protection: TLS
Replay protection: Yes
Relay protection: Yes
Hijack protection: Yes
Forge protection: Yes
MFA support: Yes
Integrity protection: TLS, internal for JWT
Encryption type: TLS, internal for JWT

XOAUTH2

Just as XOAUTH is an extension of OAUTH technology for mail servers, the XOAUTH2 protocol is a specific extension of OAUTH2. It is a variant of the protocol, the actual communication remains virtually unchanged. Roughly, the technological development can be described as OAUTH → OAUTH2 → XOAUTH2. Even in this case, the XOAUTH2 protocol is used for authentication for mail servers, i.e. for SMTP, IMAP4 and POP3 protocols. In this case, it is possible to treat the application and resource server as if they were combined into one system.

Channel Binding: No
Realms: Yes
Crypto-primitives: Runout (RSA), current (SHA256, ECDSA)
Number of pages in authentication: 4
PQC/QRC: No
ZKP: No
Crypt interface support: Under certain conditions
Tokenization: Yes
Uniqueness: Yes
Credentials protection: TLS
Replay protection: Yes
Relay protection: Yes
Hijack protection: Yes
Forge protection: Yes
MFA support: Yes
Integrity protection: TLS, internal for JWT
Encryption type: TLS, internal for JWT

OPENID20

OpenID is an extension of the OAUTH2 authorization scheme to include an identity verification method and provides a fed authorization system service. Again, support for secure password exchange is desperately weak. As part of the authentication, it supports directly MFA and rate/limit as a form of protection against password attacks. Unlike OAUTH2, it no longer supports text tokens, but only JWT tokens.
At the beginning, the user must authenticate and register the applications. Logging in is done in a simple way, where the user is redirected to an authentication server (IDP - Identity Provider) after a request for authentication, where he enters a password, or uses MFA. The password is again transmitted as open text, not in a protected way. IDP Server processes the password and any other factors, and compares it with the stored data (passwords stored e.g. using the Argon2 function). Subsequently, it sends information about the user's identity. Unlike OAUTH2, it only uses the Access Token and Refresh Token, which limits the possibilities of exchanging information to three basic methods – Authorization Code flow, Hybrid Flow and Implicit flow.
Authorization Code Flow: After logging in, the authorization code and status are sent to the authorization server. This creates an ID Token, Access Token and Refresh token, which it sends to the user. This provides the Access Token to the application, Refresh uses the token to request a new Access Token. It uses the ID token to verify the identity of the applicant. This approach is similar to Authorization Code Grant and is the preferred option.
Hybrid Flow is similar to Authorization Code Flow. Unlike the previous one, however, Access Token is obtained immediately based on the authorization code, it is not necessary to prove ownership of the authorization code. On the one hand, this simplifies the operation, on the other hand, it also limits the possibilities of controlling the access permissions. From a certain point of view, this can be seen as a security weakness.
Implicit Flow: It is similar to Implicit Grant. It is currently not recommended. At initial login, it does not use the authorization code to obtain Access Token, therefore there is a higher risk of misuse.
As in the case of OAUTH2 and OAUTHBEARER, JWT tokens and their contents can be protected using the following algorithms:
For Access Token and for Refresh Token: For JWT, HMAC-SHA256 is used for symmetric signature, for asymmetric RSA/RSASSA-PKCS1-v1_5 or ECDSA. For content encryption, AES-GCM is recommended for JWT.
For Authorization Code: cryptographic protection is not used, content is generated using a secure randomness generator. For content encryption, AES-GCM is recommended for JWT.

Channel Binding: No
Realms: Yes
Crypto: Runtime (RSA), current (SHA256, ECDSA)
Number of pages at authentication: 3 to 4
PQC/QRC: No
ZKP: No
Crypt interface support: Under certain conditions
Tokenization: Yes
Uniqueness: Yes
Credentials protection: TLS
Replay protection: Yes
Relay protection: Yes
Hijack protection: Yes
Forge protection: Yes
MFA support: Yes
Integrity protection: TLS, internal for JWT
Encryption type: TLS, internal for JWT

SAML

This is an open-source OASIS (Organization for the Advancement of Structured Information Standards) standard. The proprietary SAML language originated from AuthXML, ITMP (Information Technology Markup Language), S2ML (Security Services Markup Language), X-TASS (XML Trust Assertion Service Specification). From a realisation point of view, this is an XML scheme that allows to define and prove several basic states. It is an authentication, authorization or specific attribute state. Information is exchanged at different levels within this protocol. Only five examples are given for each of these levels. This material is not intended to provide an exhaustive description of the SAML standard, only an idea of how it works.
Assertions: this is a number of types of documents that contain information relevant for logging in. This is user information and information related to authentication. Most of the information given is of limited validity (Assertion Expiry), limited use for specific service providers (Audience restriction) and must always be digitally signed. Custom assertions can be e.g. Authentication Assertion (when and how the user was authenticated), Attribute Assertion (user parameters, i.e. name, group, role), Delegation Assertions (delegating authority to another entity), Subject Confirmation Assertion (how the user is authenticated), Session Assertion (what parameters and session duration) and more.
Protocols: this is a definition of an assertions transfer. Examples include Authentication Request Protocol (Service Provider asks Identity Provider to authenticate assertions), Artifact Resolution Protocol (allows you to obtain SAML aserce based on an artifact), Name Identifier Management Protocol (changing user ID between Service Provider and Identity Provider), Name Identifier Mapping Protocol (exchanging user ID between Service Provider and Identity Provider), Single Logout Protocol (allows you to unsubscribe from services), and more.
Bindings: defines requests and how to transfer. Examples include HTTP Artifact Binding (uses HTTP to transfer artifacts, artifacts contain negotiation and transfer assertions), HTTP Redirect Binding (uses HTTP redirection with parameters in URL), HTTP POST Binding (SAML aserce is sent as a form POST), PAOS Binding (Reverse SOAP over HTTP for communication between client and Identity Provider), SMTP Binding (uses SMTP for exchanging messages via email), and much more.
Profiles: defines the use of assertions to meet authentication and authorization requirements. For example, there are Attribute Query Profile (allows SP to request IdP for additional user attributes), Enhanced Client or Proxy (ECP) Profile (allows client authentication instead of browser, Mobile SSO Profile (optimized for logging in from mobile devices), Single Logout Profile (allows user logout on all connected services), Web Browser SSO Profile (allows user to log in once and then access multiple services) and many more.
Security: Defines different types of security assertions, protocols and bindings. For one thing, it can be a security at the transport level SSL/TLS layer. At the message level, XML encryption is used, which uses AES-CBC or AES-GCM with 128b/256b keys. Messages can also be digitally signed, for which a signature is used using the RSA algorithm (RSA+SHA256) or ECDSA (ECDSA NIST P-256+SHA256).
The system itself uses two main methods to control the allocation of permissions, a method enforced by the service provider (e.g. application or service provider) and a method enforced by the identity provider.

SP-Initiated SSO (Service Provider Initiated)
- The user requests access to an application or service (Service Provider).
- The Service Provider redirects the user to the Identity Provider with an authentication request (SAML AuthnRequest).
- The Identity Provider authenticates the user (password, MFA, certificate, etc.).
- The Identity Provider creates SAML Assertion and redirects the user back to the Service Provider.
- The Service Provider authenticates SAML Assertion and logs the user.
- The application asks the authorization system for access to data (OAuth, policy rules).
- The authorization system authenticates access and allows the application to obtain data from the provider.

IdP-Initiated SSO (Identity Provider Initiated)
- The user logs the Identity Provider directly.
- The Identity Provider creates SAML Assertion and redirects the user to the Service Provider.
- The Service Provider verifies the SAML Assertion and logs the user.
- The application asks the authorization system for access to the data.
- The authorization system verifies the access and allows the application to obtain the data.

SAML allows the use of various types of authentication mechanisms. Of course, it supports the PLAIN/LOGIN method, which is protected only by TLS. Furthermore, authentication using digital certificates RSA or ECDSA, Kerberos, smart cards and FIDO2/WebAuthn, or external identities provided e.g. by OAuth2, OpenID Connect and others. In addition to the actual authentication, authentication information can be provided by SSO, where both transport encryption and encryption of the own transferred assertion are used for the transfer assertion data (more about the encryption assertion is in the security property).

Channel Binding: No
Realms: Yes
Crypto-primitives: Run-Out (RSA), Current (SHA256, ECDSA)
Number of pages at authentication: 3 to 5
PQC/QRC: No
ZKP: No
Crypt interface support: Under certain conditions
Tokenization: Yes
Uniqueness: Yes
Credentials protection: TLS
Replay protection: Yes
Relay protection: Yes
Hijack protection: Yes
Forge protection: Yes
MFA support: Yes
Integrity protection: TLS, internal for JWT
Encryption type: TLS, internal for JWT

Conclusion

This episode has completed an overview of the mechanisms used. Based on the information provided, it is obvious that some mechanisms are not suitable to use, while for others it is necessary to be extremely careful about the setting and configuration of both the environment and the protection layers used. Despite all the protections, the most common method for user authentication is to send this information in plaintext (PLAIN or LOGIN method), where the only protection is the TLS layer. In this case, however, mTLS (Mutual TLS, i.e. mutual verification of certificates within TLS) is required for adequate protection. In another case, any SSL inspection will allow an attacker to access authentication data. Unfortunately, any form of MFA does not prevent against these types of attacks.
In the next part SASL Analysis, Part Five, the libraries used will be discussed and criticism and evaluation of individual schemes will be given, the risks will be specified and recommendations on how to prevent these problems.

Autor článku:

Jan Dušátko

Jan Dušátko has been working with computers and computer security for almost a quarter of a century. In the field of cryptography, he has cooperated with leading experts such as Vlastimil Klíma or Tomáš Rosa. Currently he works as a security consultant, his main focus is on topics related to cryptography, security, e-mail communication and Linux systems.