A Brief Guide to Identity Federation Frameworks

One of the challenges in designing and implementing a cybersecurity program is reconciling the somewhat disparate goals of establishing and maintaining secure systems while preserving end user access and efficiency. You can implement the most secure system in the world, but if your end users can’t access your systems or access them efficiently, it’s all for naught. One of the solutions that has been used to bring these goals more in line is the concept of federated identities.  A federated identity is an identity, i.e., a user account, that is shared among multiple systems. You’re likely familiar with this concept just from using everyday websites like Twitter, Reddit, LinkedIn, and Spotify, which all allow you to login to their websites with your user account from certain other websites (such as Google, Apple, Facebook, and Microsoft). For example, I can login to my LinkedIn account using my Google account. In this example, my Google account is acting as a federated identity that I’m allowed to “share” with other websites (thus allowing me to login to these sites with my Google account using what’s referred to as single sign-on or SSO). This is due to a trust relationship that has been established between those websites and Google. There are several benefits to both organizations and end users when implementing federated identities and SSO. End users don’t need to create and remember passwords for every site they visit, thus making them less likely to use insecure passwords. With the advent and increased popularity of the concept of federated identity, several frameworks have been developed to implement SSO using federated identities. Frameworks provide standard mechanisms that can be used to design these systems, but they do not specifically define how those mechanisms must be implemented. Thus, design and implementation can vary from system to system. Below is a brief synopsis of the most common frameworks in use today. 

SAML (Security Assertion Markup Language)

• SAML is used for authentication and authorization.
  • Authentication is the concept of verifying your identity, often via a username and password, but also via some forms of advanced authentication such as push notifications, text messages, or phone calls. 
  • Authorization occurs after authentication and defines what the verified end user should be allowed to access, i.e., what permissions the end user has. 
• The most recent version is SAML 2.0, but the previous version, SAML 1.1, is also still being used in various capacities. 
• SAML is both a framework and a type of token. Think of a token like an access card that you would use to access a building, except in this case the token is entirely digital and is used to access websites or other digital systems. 
  • A SAML token is XML encoded. 
• It is commonly used with browser-based applications, like websites. It is less commonly used with desktop or native applications and mobile applications, because the XML token is more difficult to use with these kinds of applications given its large size. 
• The SAML framework supports both IdP (Identity Provider), and SP (Service Provider)-initiated flows (a flow describes how the traffic is routed). An IdP is a service (such as Google) that stores and manages a user’s federated identity. A SP is a separate service (such as LinkedIn) that has a trust relationship with the IdP and is configured to allow its users to login with their IdP identities. 
  • SP-initiated flow: A user accesses the login interface of a service (the SP) they wish to utilize. The SP will then redirect the user to the IdP to login (usually either after the user enters their username or after they’ve indicated they wish to sign in via an IdP). At the time of this redirect, the SP sends an authentication request to the IdP. Once the IdP authenticates the user’s identity, it generates a SAML token (also known as a SAML assertion), which contains various required and optional information. This information usually includes the authenticating user’s username, statements about how and when the user authenticated with the IdP, and may include other information about the user, such as their name, email address, phone number, etc. Additionally, the SAML token may include authorization information that will indicate to the SP to which resources the user is allowed access. This SAML token is then sent to and validated by the SP. The SP uses this token to authenticate (and authorize, if such information is included) the user.  
  • IdP-initiated flow: A user signs in to their IdP (such as Microsoft) and initiates a login to a preconfigured (often third-party) application (the SP), usually via an application dashboard. The SP does not initiate the authentication flow via an authentication request, rather the flow is initiated from the IdP. Once the user is authenticated and attempts to access the SP from the IdP, the IdP generates the SAML token, as described above, and sends it to the SP, which uses it to authenticate (and possibly authorize) the user. 
  • While the framework supports both flows, not all IdPs and SPs support both. The SP-initiated flow is the most frequently supported of the two types. 

WS-Federation

• WS-Fed is used for authentication and authorization.
• It is predominantly used for federation services for Microsoft products, such as Microsoft 365.
• It has an authentication flow that is similar to SAML. It also supports IdP (aka STS) and SP-initiated flows. 
• WS-Fed uses a SAML 1.1 token for authentication and authorization.

OAuth (Open Authentication)

• Used on its own, OAuth is only used for authorization. The current version in use is OAuth 2.0.
• OAuth supports three different flow types: authorization code flow, implicit flow, and hybrid flow.
  • Authorization code flow is the most common of the three. Implicit flow is no longer recommended for various security reasons, including token leakage. 
• It can be used with browser-based applications, desktop or native applications, and mobile applications. 
• The OAuth framework does not prescribe a particular token type, but JSON web tokens (JWTs or “jots”) are frequently used. 
• OAuth is considered consent-based authorization and it will often involve the user being asked to agree to third-party access to their information and/or to allow the third-party to take some action on the user’s behalf. 
• Example: You’ve (the resource owner) downloaded an application called Shop (the client), which is a shipment tracking app, to help you keep track of the status of your online purchases. Shop has an integration with Gmail, which allows it to read shipment confirmation emails and pull this content into the app to be tracked. When you first initiate this link to your Gmail account, the app will redirect you to Gmail. During this redirection, the app sends a request to Gmail (sent to the authorization server) asking for specifically defined access (defined using scopes) to your Gmail account. Once you’re logged into Gmail (OAuth does not handle this part, remember it’s only used for authorization), it will prompt you to consent to the access being requested by Shop. Once you approve this access, Gmail will generate an access token, which only allows access to that to which you’ve consented. The access token is sent to Shop to be used to access your emails (it can be used to access what’s known as the resource server). 
  • Prior to OAuth, the standard way to allow this access was to give Shop your Gmail username and password, thus allowing it unfettered access to your Gmail account. This is, of course, not ideal for many reasons. With OAuth, you do not provide credentials directly to Shop and Shop only has the limited access to which you’ve consented. 

OIDC (OpenID Connect)

• OIDC is used for authentication and authorization.
• It runs on top of OAuth 2.0 and adds authentication.
• The OIDC framework prescribes JWTs as the required token type. 
• Like OAuth, OIDC is a framework that supports three flows: authentication code flow, implicit flow, and hybrid flow. 
• Just like with OAuth, the client (known as the relying party in OIDC terms) receives an access token from the authorization server to be used to access the resource server. With OIDC, the client also receives an ID token, which includes claims. Claims are key:value pairs that include information asserted about the authenticating user (aka the resource owner). As an example, firstname:Kelsey is a claim that might be included in an ID token.
  • The claims that are to be included in the ID token are defined in the request from the client to the authorization server using scopes. 
    • Scopes are used to define what information the client can access about the resource owner, as well as what actions the client can take on the resource owner’s behalf. A request sent by a client using OIDC will always include a scope of openid. OAuth does not define any particular values for scopes, they must be pre-configured between the client and the authorization server. OIDC, on the other hand, does define a few standard scopes, which include standard claims. As an example, the profile scope includes seven standard claims (name, given_name, family_name, middle_name, nickname, picture, and updated_at).