All you need to know about Auth in the Web. Identity and Access Management.

Life before Identity and Access Management systems

Each website/app has independent and own database. It’s means all user credentials applies only for this site.

Identity and Access Management (IAM)

Identity management

Access control or Access management

  • Identification — The process by which a subject identifies itself to the access control system
  • Authentication — Verification of the subject’s identity
  • Authorization — The decision to allow or deny access to an object
  • Authorized — Those who have presented authenticated credentials and have been approved for access to the resource
  • Unauthorized — Those who have presented authenticated credentials but are not approved for access to the resource
  • Unknown — Those who have not presented authenticated credentials

What are Identity and access management?

So we can think of Identity and Access Management as getting the right people the right access to the right resources at the right time.

The difference between Identity and Access Management

  • Identity Management is all about managing the attributes related to the “Identity”, group of users, or another identity that may require access from time to time.
  • Access Management is all about evaluating those attributes based on existing policies and making a yes or no access decision based upon those attributes.

Terms we should know

Identification or Identity Proofing

Authentication

  • Something you know — Secret knowledge, such as a password
  • Something you have — A token or device
  • Something you are — Unique physical characteristics of a person, such as those that can be detected by a retinal or iris scan, fingerprint scan, or voice analysis”

Authorization

Identity Provider (IDP)

Service Provider (SP)

Session/Cookie-based authentication

  1. User submits login credentials (email/username and password)
  2. Server verifies the credentials against the Database
  3. Server creates a temporary user Session
  4. Server sends a cookie with a Session ID
  5. On each request user sends the cookie with each request (that how cookies works)
  6. On each request server validates the cookie in request against the session store & grand access
  7. When a user logs out, the server destroys the Session and cleans the cookie for the user.
  1. Stateful. Need to store session in a database on server. It’s not good for API. APIs provide one-time resources for authenticated end-users and don’t need to keep track of user sessions. Cookies don’t work perfectly in this case, since they track and verify active sessions.
  2. CORS. Cookies + CORS don’t play well across different domains.
  3. CSRF. You need to prevent your API from CSRF attack.
  4. Mobile platform. Cookies is for web browser. You need to do extra work for mobile native platform which is not easy to implement.

Token-based authentication

  1. User submits login credentials (email/username and password)
  2. Server verifies the credentials against the Database
  3. Server generates temporary tokens and embeds user data into them (these tokens are called Access Token and Refresh Token. The Access Token will have less expiry time (60 minutes) and Refresh Token will have long expiry (10 days).
  4. Server responds back with these tokens
  5. User stores these tokens on client-side
  6. User sends Access Token along with each request
  7. On each request server validates the Access Token & grand access (if the access token expired the client requests a new Access Token by sending Refresh Token to the server, and the server validates the Refresh token and if it’s valid issues a new access token (and, optionally, a new refresh token). Example of Refresh Token flow check Refresh Token in OAuth 2.0 Authorization Framework
  8. When user logs out, token is cleared from client storage.

Session or Token Authentication

Access Token

Refresh Token

JWT (JSON Web Tokens)

  • Header — contains metadata about the token (type, hashing algorithm etc.)
  • Payload — contains claims (statements about an entity — for example a name) and additional data.
  • Signature — is the result of the encoded header, the encoded payload, signed against a secret.

Events in the Life of an Identity

Identity and access provisioning life cycle

Resource: Solving Identity Management in Modern Applications by Yvonne Wilson and Abhishek Hingnikar

Single sign-on (SSO)

How does SSO work?

Federated Identity

  • Authentication — validating user credentials and establishing the identity of the user.
  • Authorization access restrictions (e.g., is the user allowed to access X resource?).
  • User attributes exchange — deals with data sharing across different user management systems. For instance, fields such as “real name” may be present in multiple systems. A federated identity system prevents data duplication by linking the related attributes.
  • User management — related to the administration (creation, deletion, update) of user accounts. A federated identity system usually provides the means for administrators (or users) to handle accounts across domains or subsystems.

How Federated Identity works

  1. The user attempts to access a resource controlled by a server.
  2. The user does not have the proper credentials to access the resource, so the server redirects the user to the authorization server. The authorization server is configured to let users log-in using the credentials managed by an identity provider.
  3. The user gets redirected by the authorization server to the identity’s provider log-in screen.
  4. The user logs-in successfully and gets redirected to the authorization server. The authorization server uses the credentials provided by the identity provider to access the credentials required by the resource server.
  5. The user gets redirected to the resource server by the authorization server. The request now has the correct credentials required to access the resource.
  6. The user gets access to the resource successfully.

Components of federation

  • Identity Provider or IDPIDP can be federated to multiple SPs.
  • Service Provider or SPSP has nothing to do with the authentication of the user. It trusts the IDP to take care of that. All the SP cares about is that the user was authenticated properly.
  • Assertion — the message that is sent between the IDP and SP. It’s containse attributes that the SP needs to create a user session. And it’s cryptographically signed so the SP can trust that it came from the right IDP.

Federated Identity vs Single Sign-on

Security Assertion Markup Language (SAML 2.0)

ALERT: To implement SSO by using SAML you need to relay good understanding of this protocol cuz it’s can be prone to exploits if not implemented correctly.

Use SAML only if you have requirements or you can’t adopt OAuth and OpenID Connect!!!

Benefits of SAML Authentication

  • Improved User Experience — Users only need to sign in one time to access multiple service providers. This allows for a faster authentication process and less expectation of the user to remember multiple login credentials for every application. In the example above, that user could have clicked on any of the other icons in their dashboard and been promptly logged in without ever having to enter more credentials!
  • Increased Security — SAML provides a single point of authentication, which happens at a secure identity provider. Then, SAML transfers the identity information to the service providers. This form of authentication ensures that credentials are only sent to the IdP directly.
  • Loose Coupling of Directories — SAML doesn’t require user information to be maintained and synchronized between directories.
  • Reduced Costs for Service Providers — With SAML, you don’t have to maintain account information across multiple services. The identity provider bears this burden.

SAML Concepts and Terminology

  • Subject — An entity about which security information will be exchanged. A subject usually refers to a person, but can be any entity capable of authentication, including a software program. For the use cases we’ll discuss, the subject is generally a user of an application.
  • SAML Profile — A specification that defines how to use SAML messages for a business use case such as cross-domain single sign-on.
  • SAML Identity Provider — A role defined for the SAML cross-domain single sign-on profile. An identity provider is a server which issues SAML assertions about an authenticated subject, in the context of cross- domain single sign-on.
  • SAML Service Provider — Another role defined for the SAML cross-domain single sign-on profile. A service provider delegates authentication to an identity provider and relies on information about an authenticated subject in a SAML assertion issued by an identity provider in the context of cross-domain single sign-on.
  • SAML Trust Relationship — An agreement between a SAML service provider and a SAML identity provider whereby the service provider trusts assertions issued by the identity provider.
  • SAML Protocol Binding — A description of how SAML message elements are mapped onto standard communication protocols, such as HTTP, for transmission between service providers and identity providers. In practice, SAML request and response messages are typically sent over HTTPS using either HTTP-Redirect or HTTP-POST, using the HTTP-Redirect and HTTP-POST bindings, respectively.
  • SAML Request — request that SP sends to IdP. Example
  • SAML Response — response that IdP sends to SP. Example
  • SAML Issuer — EntityID (unique identifier) of the service provider.
  • Recipient — EntityID (unique identifier) of the service provider.
  • ID — generated number for identification.
  • InResponseTo — the ID of the SAML Request that this response belongs to.
  • Assertion — An XML-based message that contains security information about a subject. It’s XML-formatted tokens that are used to transfer user identity information, such as the authentication, attribute, and entitlement information, in the messages. SAML Assertion message (XML-formatted token) tells a Service Provider that a user is signed in. SAML Assertions contain all the information necessary for a Service Provider to confirm user identity, including the source of the assertion, the time it was issued, and the conditions that make the assertion valid.
  • SAML Assertion Consumer Service or ACS — responsible for receiving the SAML Response from the IdP. Checking the Assertion signatures and validating the document.
  • AssertionConsumerServiceURL — the SAML URL interface of the service provider, where the Identity provider sends the authentication token.
  • Attributes — with SAML Response there’s going to be other information about the User, like first name, last name, email and etc.
  • Relay State — is a way for IdP to remember where a user was before authentication. It allows the SP to send along, in the SAML Request, where a user was before the user triggered an authentication, the IdP preserves that Relay State and then sends it back to the SP, the Assertion Consumer Service then can determine where that user needs to go after authentication has been completed.
  • SAML Trust — configuration between IdP and SP. There are certain pieces of information that are shared: signing certificate, Entity ID aka Issuer. This information is shared between SP and IdP so they can have a trust that allows them to validate the communications in SAML Requests and SAML Responses.
  • SAML Metadata — is a convenience feature that really allows self-configuration between IdP and SP. It means instead of manually grabbing a certificate, different endpoints, EntryId/Issuer information and etc. from IdP to plugin into SP manually and vice versa. The metadata allows you to just share the entire XML configuration file or share the URL to this XML configuration file and then the SP and IdP can self-configure themselves based on the information within this configuration file. It makes a lot less manual work and makes it more convenient.

How does SAML work?

  • User Agent (for ex. Browser/User)
  • Service Provider or SP — application you try to access.
  • Identity Provider or IdP — centralized service that verifies who you are.
  • Metadata — this simply defines the rules of who an identity provider is or service provider. Metadata is XML that follows a schema which is governed by SAML spesification.
  • Core/Protocols — XML schemas. These schemas describe the messages that are being sent back and forth.
  • Binding — description of how do we send messages back and forth.
  • Profile — combinations of protocols, assertions, and bindings that are used together to create a federation and enable federated single sign-on.
  • Conformance — tells us how to conform to all specifications above.

OAuth and OpenId Connect

What is OAuth?

OAuth Concepts and Terminology

  • Client (the application)— system that requires access to the protected resources. To access resources, the Client must hold the appropriate Access Token.
  • Resource Owner (the user)— user or system that owns the protected resources and can grant access to them.
  • Resource Server (the API) — a server that protects the user’s resources and receives access requests from the Client. It accepts and validates an Access Token from the Client and returns the appropriate resources to it.
  • Authorization server (can be the same server as the API)— the authority that is able to grant access to resources.
  • Confidential Client — An application that runs on a protected server and can securely store confidential secrets to authenticate itself to an authorization server or use another secure authentication mechanism for that purpose.
  • Public Client — An application that executes primarily on the user’s client device (native application) or in the client browser and cannot securely store a secret or use other means to authenticate itself to an authorization server.
  • Authorization Code — An intermediary, opaque code returned to an application and used to obtain an access token and optionally a refresh token. Each authorization code is used once.
  • Access Token — a string that a Client uses to make requests to the Resource Server (API). Access tokens do not have to be in any particular format. ID Token vs Access Token
  • Refresh Token — a string that a Client can use to get a new Access Token without the user’s interaction (has to be stored securely by clients). Learn more about Refresh Tokens and How to Use Them Securely.
  • Redirect URIs or Reply URL — is the location where the authorization server sends the user after a user successfully authorizes an application. More.
  • Scopes — limit an app’s access to a user’s data. It specifies exactly the reason for which access to resources may be granted. More
  1. The Client requests authorization (authorization request) from the Authorization server, supplying the client id and secret to as identification; it also provides the scopes and an endpoint URI (redirect URI) to send the Access Token or the Authorization Code to.
  2. The Authorization server authenticates the Client and verifies that the requested scopes are permitted.
  3. The Resource owner interacts with the Authorization server to grant access.
  4. The Authorization server redirects back to the Client with either an Authorization Code or Access Token, depending on the grant type, as it will be explained in the next section. A Refresh Token may also be returned.
  5. With the Access Token, the Client requests access to the resource from the Resource Server.

What is OpenID Connect (OIDC)?

ID Token

Overview of OAuth and OpenId Connect

Conclusion

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store