Skip to main content

Auth/IAM Choices

Cloud IAM Providers​

  • Cloud services can help with all these IAM concepts.

Benefits of a 3rd-party cloud IAM provider:

  • Comprehensive set of features and functionalities,

  • Organizations can manage and control access to resources and services, and

  • Enforce compliance and security policies from a central source

  • In a centralized and automated manner.

  • AWS Identity and Access Management (IAM) service allows you to manage access to AWS resources. It enables you to create and manage AWS users and groups, and to use permissions to allow and deny their access to AWS resources.

  • Azure Active Directory (Azure AD) which is a multi-tenant cloud-based directory and identity management service. It allows you to authenticate and authorize access to resources and applications, and to manage roles and permissions for users and groups.

  • Google Cloud Identity and Access Management (IAM) service allows you to control access to your resources hosted on Google Cloud Platform (GCP) by creating and managing roles and permissions for users, groups, and service accounts.

  • Okta is an IAM solution that provides identity management and access management capabilities. It allows organizations to manage access to web and mobile applications, and to automate the provisioning and deprovisioning of user accounts. Okta also provides an identity platform that allows organizations to integrate with other identity providers, such as Active Directory or LDAP, and to enable single sign-on (SSO) for users.

  • Auth0 is now owned by Okta and is similar but targets smaller-size startups, developers and businesses.

  • SailPoint is an IAM solution that provides identity governance and access management capabilities. It allows organizations to manage access to on-premises, cloud, and hybrid resources, and to automate the provisioning, deprovisioning, and certification of access rights. SailPoint also provides an identity governance framework that allows organizations to enforce compliance and security policies and to report on user activity and access rights.

Types of Logins​

  • Email and password login:
    • A traditional login method that involves entering an email address and password to gain access to the system.
    • Password is typically hashed and stored in a database.
    • Most basic login, not recommended as presents many security risks.
  • Social media login:
    • A login method that allows users to log in using their existing social media accounts, such as Facebook or Twitter.
    • Common and works well with social media users.
  • Single sign-on (SSO):
    • Allows users to log in with a single set of credentials across multiple systems or applications.
    • Recommended, used with OAuth, OIDC, SAML or social login
    • Numerous provider sevices like Okta, Auth0 and AWS Cognito
  • OAuth login:
    • Uses the OAuth protocol, which is an open standard for authorization, to authenticate the user.
    • Recommended, used with OAuth, OIDC, SAML or social login
  • OpenID Connect login:
    • Uses the OpenID Connect protocol, which is an extension of OAuth that has additional user profile info included.
  • Two-factor authentication (2FA):
    • A login method that requires an additional form of verification, such as a one-time code sent to a phone or a fingerprint scan, in addition to a password.
  • Biometric login:
    • A login method that uses biometric data, such as a fingerprint or facial recognition, to verify the user's identity.
  • Token-based login:
    • A login method that uses a token, such as a JSON Web Token (JWT), to authenticate the user.
  • Smart card login:
    • Uses a smart card, such as a credit card with a chip, to authenticate the user.
  • Kerberos login:
    • Uses the Kerberos protocol, which is a network authentication protocol.
  • SMS-based login:
    • Uses a one-time code sent to the user's phone via SMS to verify their identity.
  • QR code login:
    • Uses a QR code, which the user scans with their mobile device, to initiate the login process.
  • Magic link login:
    • Uses a link sent to the user's email address to initiate the login process.
  • Voice recognition login:
    • A login method that uses voice recognition technology to verify the user's identity.
  • Hardware token login:
    • A login method that uses a small physical device, such as a key fob, to generate a one-time code that the user enters to log in.

Which OAuth 2.0 Flow Should I Use?​

OAuth 2.0, OpenID Connect (OIDC), and Security Assertion Markup Language (SAML)​

OAuth, OpenID Connect (OIDC), and Security Assertion Markup Language (SAML) are all different protocols that are used to authenticate and authorize users to access resources and services.

  • OAuth is an open standard for authorization.

    • It allows users to grant access to their resources, such as data or services, to another application without sharing their credentials.
    • OAuth is commonly used to allow users to log in to a website or application using their existing accounts on other websites, such as Google or Facebook.

  • OpenID Connect (OIDC) is an extension of OAuth 2.0 that adds an identity layer.

    • OIDC allows users to authenticate themselves and to provide identity information, such as their name and email address, to the application.
    • It also allows the application to verify the identity of the user and to obtain additional information about the user from the identity provider.

  • SAML is an XML-based standard for exchanging authentication and authorization data between an identity provider (IdP) and a service provider (SP).

    • SAML enables Single Sign-On (SSO) across different domains, and is often used to provide SSO for enterprise applications, such as Salesforce, Office 365, and Google Workspace.

OAuth 2.0 and OIDC flows​

There are several different types of OAuth/OIDC credential flows, each with its own specific use case and security considerations:

  • Authorization Code Grant: This flow is used when a user wants to grant an application access to their resources. The application redirects the user to the authorization server, where the user logs in and grants the application access. The authorization server then sends an authorization code back to the application, which the application can exchange for an access token.

  • Implicit Grant (deprecated but still in usage): This flow is similar to the Authorization Code Grant, but the access token is returned to the application directly, without the need for an authorization code. This flow is typically used for client-side applications, such as JavaScript web apps or mobile apps, that cannot keep a client secret secure.

  • PKCE (Proof Key for Code Exchange) - (common frontend) recommended clientside - is an extension to the OAuth 2.0 authorization code flow, which is designed to improve the security of public clients, such as JavaScript-based single-page apps (SPA) or mobile apps.

    In the normal OAuth 2.0 authorization code flow, the client sends the user to the authorization server, where the user authenticates and grants access. The authorization server then sends an authorization code back to the client, which the client can exchange for an access token. However, this flow is vulnerable to a number of attacks, such as the authorization code being intercepted or the client's secret being compromised.

    PKCE solves this problem by introducing a secret that is generated by the client and sent to the authorization server along with the authorization code. The authorization server can then use this secret to verify that the client requesting the access token is the same one that requested the authorization code.

    PKCE (Proof Key for Code Exchange) is an extension to the OAuth 2.0 authorization code flow, which is designed to improve the security of public clients, such as JavaScript-based single-page apps (SPA) or mobile apps.

    In the normal OAuth 2.0 authorization code flow, the client sends the user to the authorization server, where the user authenticates and grants access. The authorization server then sends an authorization code back to the client, which the client can exchange for an access token. However, this flow is vulnerable to a number of attacks, such as the authorization code being intercepted or the client's secret being compromised.

    PKCE solves this problem by introducing a secret that is generated by the client and sent to the authorization server along with the authorization code. The authorization server can then use this secret to verify that the client requesting the access token is the same one that requested the authorization code.

    The process of PKCE involves the following steps:

    1. The client generates a cryptographically random code_verifier, and then creates a code_challenge by applying the SHA-256 hashing function to the code_verifier.
    2. The client redirects the user to the authorization server, including the code_challenge as a query parameter.
    3. The user authenticates and grants access, and the authorization server sends an authorization code back to the client.
    4. The client sends the authorization code and the code_verifier to the token endpoint, and the authorization server uses the code_challenge to verify that the client requesting the access token is the same one that requested the authorization code.
    5. The authorization server issues an access token, which the client can use to access protected resources.
  • Resource Owner Password Credentials Grant: This flow is used when a user wants to grant an application access to their resources, but the application already has the user's credentials. The application sends the user's credentials to the authorization server, which returns an access token if the credentials are valid. This flow is typically used for trusted applications, such as those owned by the same organization as the user.

* Client Credentials Grant (common backend): This flow is used when an application wants to access its own resources, without any user involvement. The application sends its own credentials to the authorization server, which returns an access token if the credentials are valid.

  • Device Code Grant: This flow is used when an application wants to access resources on behalf of a user but the user is unable to input credentials. The application requests for a device code and user-code from the authorization server, the user will then enter the user-code on a device capable of inputting. The authorization server then returns the access token to the application.

Other related terms:

  • Access Token: A token that is issued by the authorization server and that can be used to access a protected resource.
  • Refresh Token: A token that is issued along with the access token and that can be used to obtain a new access token, without the need for the user to re-authenticate.
  • Scope: A set of permissions that the user can grant to the application.
  • Identity Token: A token that contains information about the user, such as their name and email address.
  • ID Token: A JSON Web Token (JWT) that contains information about the user and the authentication session, it is returned to the application after a successful authentication.
  • Claims: A set of information that is included in the ID token and that can be used to make authorization decisions.
  • JWT: A JSON object that is used to securely transmit information between parties. JWT is often used to transmit access tokens and ID tokens.
  • Nonce: A value that is included in the authentication request and that is returned in the ID token, to help prevent replay attacks.
  • Audience: Identifies the intended recipient of the JWT.
  • Issuer: Identifies the entity that issued the JWT.

AWS IAM/Login Services​