identity federation<\/a>. SAML relays user credentials from an IdP that owns and maintains identities to verify access rights and SPs. Service providers require authentication prior to granting users access to the resource. Each user (or group) has attributes that outline profile information and assert what exactly they\u2019re authorized to access.<\/p>\n\n\n\nSAML uses extensible markup language (XML) metadata documents (SAML tokens) for an assertion process to verify a user\u2019s identity and access privileges.<\/p>\n\n\n\n
Developers use SAML plugins within apps or resources for an SSO login experience that assures security practices are being followed and credentials\/assertions determine who can access an application. Additionally, SAML can be used to control what resources an identity can access in an application. <\/p>\n\n\n\n
SAML is comprised of several core components that make it possible to exchange user information for access control, including IdP, client, attributes, to the SP. <\/p>\n\n\n\n
Identity Provider (IdP)<\/h3>\n\n\n\n An IdP is a service that maintains and manages digital identities to verify user credentials throughout applications, networks, and web services. It\u2019s primary role is to safeguard the integrity of user credentials and federate user identity where SSO logins are desired.<\/p>\n\n\n\n
Client<\/h3>\n\n\n\n Clients are your users who will authenticate into a service using the credentials that are being managed by an IdP. For example, your employer may use SAML for SSO access into the services that you need to work, using your company email address and password.<\/p>\n\n\n\n
Attribute<\/h3>\n\n\n\n SAML transfers messages, called assertions, from an IdP to a service provider. These assertions set all relevant security requirements for the transaction by authenticating, authorizing, and determining the level of permissions a client will receive. Attributes such as \u201cdept,\u201d \u201cemail,\u201d and \u201crole,\u201d are used to enforce access management and access control. Sometimes, custom attributes are used so that SAML can be extended for use with custom software.<\/p>\n\n\n\n
Service Provider (SP)<\/h3>\n\n\n\n Service providers are a resource that users authenticate into using SAML SSO, usually a private website or application. They receive, accept, or deny assertions from IdPs for each client profile prior to granting users access. SPs send requests to IdPs to begin the authentication process, and the client\u2019s assertion is received in response. The process is sometimes reversed when an IdP initiates the sign-in flow to assert user identity. It can be initiated either way.<\/p>\n\n\n\n
How OIDC Works<\/h2>\n\n\n\n OIDC extends the OAuth protocol so that client services (your applications) verify user identities and exchange profile information through OpenID providers via RESTful APIs that dispatch JSON web tokens (JWTs) to share information during the authentication process. The providers are essentially authentication servers. Many developers are attracted to this approach because it\u2019s highly scalable, flexible across platforms, and is relatively simple to implement. Its main components are a unique user ID workflow with OAuth underpinnings.<\/p>\n\n\n\n
User Authentication<\/h3>\n\n\n\n A resource owner (your users) authenticates and is authorized to access a client application by way of an authorization server that grants an access token that allows apps to receive consented information from a UserInfo endpoint. A UserInfo endpoint is a protected resource found on an OpenID server that contains claims (assertions) about each user in a JSON object. Authentication information is then encoded within an ID Token that\u2019s received by the app. This information is cached for scalable performance and personalizes the end-user experience.<\/p>\n\n\n\nSource: OpenID Foundation<\/em><\/figcaption><\/figure>\n\n\n\nBuilt on OAuth 2.0 Protocol<\/h3>\n\n\n\n OIDC is built on top of the OAuth 2.0 framework, which is a standard that grants third-party apps and service access to user ID resources. No user credentials are sent over the wire or stored on third-party servers, which increases security and ease of use for IT administrators.<\/p>\n\n\n\n