Auth 101: Your Guide to AuthN, AuthZ, and Friends

I had a serious conversation with my dad the other day. He poured me a glass of whiskey, and said gravely: it’s time. You should overcome your fears and sort Auth stuff out.

In this article we will be answering questions as following:

  • authz and authn difference
  • openid and oauth difference
  • auth0 and openid difference
  • auth0 and oauth difference
  • auth0 and oidc difference
  • auth0 sso, oidc sso

Services and concepts that we will be exploring include:
(1) AuthN, (2) AuthZ, (3) SSO, (4) OpenID, (5) OAuth, (6) OIDC, (7) Auth0, (8) SAML.

Let’s get straight to the point.

1. AuthN is just an acronym for Authentication.

2. AuthZ is just an acronym for Authorization.

    Since the word “auth” is not self-explanatory at all, I prefer usage of these two acronyms.

    3. SSO is a general concept, related to AuthN. It’s not event a protocol.
    It’s just a broad concept of mechanism, that allows users to authenticate once and gain access to multiple applications or systems without re-entering their credentials for each one.
    Since it’s being focused primarly on AuthN, it should be used with additional AuthZ tools when required.

      SSO can be implemented using various protocols (e.g. OpenID, OIDC) and tools (Auth0).

      4. OpenID is an AuthN protocol that allows users to log in to multiple websites using a single set of credentials, eliminating the need for separate usernames and passwords for each site. As you see, it’s an implementation of SSO.

        For example, user creates account on Google, Facebook or Yahoo, and thereby they are able to log in to other webistes, that support OpenID.

        Building blocks of Open ID:

        → User. The individual who wants to access a service or website that supports OpenID auth.
        → OpenID Provider (OP). An entity that authenticates the user’s identity. Can be Google, Facebook, or Yahoo.
        → Relying Party (RP). A website or service that allows users to log in using OpenID.

        Although OpenID is NOT focused on authZ, it does include an authorization-like step where the user grants permission for the sharing of identity information with the relying party.

        OpenID use case: A user logs in to a website using their Google account, and the website verifies the user’s identity with Google’s OpenID service.

        5. OAuth is an AuthZ protocol, allowing users to grant websites or applications access to their information on other websites or services without sharing their passwords.

          Building blocks:
          → Resource owner – typically user
          → Client application – application that needs to access user’s data on behalf of resource owner
          → Authorization server – authenticates the resource owner and issues access tokens to the client. These access tokens are used by the client app to access protected resources on behalf of the resource owner.

          OAuth use case: A mobile app asks for permission to access a user’s contacts stored on a server (like Google Contacts) on behalf of the user. OAuth allows the user to grant the app permission without sharing their Google credentials with the app.

          6. OIDC is a protocol, that combines OpenID and OAuth. It focuses both on AuthN an AuthZ.

            Conjunction: often, OpenID and OAuth are used together, with OAuth providing the access token used for authorization in an OpenID Connect authentication flow. Thereby we get OIDC.

            The process is as following:

            1. We have OP, which is OpenID Connect Provider. It acts both like AuthN and AuthZ server.
            2. When user connects to a client app, it redirects user to the OP.
            3. OP authenticates user with username/pass or MFA.
            4. OP issues two tokens
              4.1. AuthN token (ID token). That token contains basic information about the user, and app can be sure that user is themselves.
              4.2. AuthZ token (Access token). That token can be used by client app to perform some actions on behalf of the user on services that supports OAuth.
            5. Auth0. It’s a cloud platform, that’s primarily focused on AuthN, but supports AuthZ: https://auth0.com/.

            Supported mechanisms:
            → User+pass auth
            → SSO (OIDC, SAML)
            → Google/Facebook/Twitter
            → Enterprise logins (LDAP, Active Directory, SAML)

            Auth0 provides fine-grained access control, allowing developers to define roles and permissions to control what authenticated users can do within an application.

            → It supports MFA.
            → Supports identity federation, i.e. authenticate users using their credentials from other identity providers.
            → GDPR and HIPAA compliant

            8. Bonus: authorization middleware.
            It’s a set of functions used to intercept requests before they reach the main application handlers.
            Authorization middleware can be applied to these requests to perform authentication and authorization checks based on the provided context and request information.

            Telegram channel

            If you still have any questions, feel free to ask me in the comments under this article or write me at promark33@gmail.com.

            If I saved your day, you can support me 🤝

              One thought on “Auth 101: Your Guide to AuthN, AuthZ, and Friends

              Leave a Reply

              Your email address will not be published. Required fields are marked *