Audience is the system that a token is intended for. For the ID token the audience is the
client_id of the relying party. For access tokens the audience is the resources that the token is indented for.
Authority represents a system that can provide authentication capabilities. Unit4 Identity Services is an authority, an Azure AD tenant is also an authority etc. The authority is represented as a known url.
Access tokens are credentials used to access protected resources. An access token is a string representing an authorization issued to the client.
Authentication Context Class Reference values
Space-separated string that specifies the
acr_values that the Authorization Server is being requested to use for processing this Authentication Request, with the values appearing in order of preference. For Unit4 Identity Services (U4IDS), this parameter is used to specify the tenant involved in an authentication request and optionally the IDP. If no
acr_values are submitted the partial login is shown.
A certificate holds the information about public and private keys used for encrypting and digital signatures to assure confidentiality and integrity of data. The role of the certificate is to assure that the keys are from a trusted issuer.
A statement that one subject makes about itself or another subject. For example, the statement can be about a name, identity, key, group, privilege, or capability. Claims are issued by a provider, and they are given one or more values and then packaged in security tokens that are issued by a security token service (STS).
A unique identifier that represents a specific user, application, computer, or other entity. It enables that entity to gain access to multiple resources, such as applications and network resources, without entering credentials multiple times. It also enables resources to validate requests from an entity.
A client (also called client application, application, web application etc.) is a piece of software that requests tokens from U4IDS, either for authenticating a user or for accessing a resource (also often called a relying party or RP). A client must be registered with the Identity Provider for trust.
Client credentials flow
The OAuth 2.0 Client Credentials Grant Flow permits a web service (a confidential client) to use its own credentials to authenticate when calling another web service, instead of impersonating a user. In this scenario, the client is typically a middle-tier web service, a daemon service, or web site.
Confidential client application
Confidential clients are typically web applications running on a secure server. It is Clients capable of maintaining the confidentiality of their credentials. Clients can securely store the credentials. Confidential clients are clients that can keep a secret. What you save on your web server is not accessible to anybody else, hence you can safely save keys there.
A client secret is a shared value known to the client and U4IDS. The client secret is used to authenticate the client against the token endpoint. Client secrets are generated and published by U4IDS.
The Identity Server does not authenticate the client, but relies on the tenants external Identity Provider (IdP), a federation gateway between the client and customers identity provider. In the chain of trust the customer must register the Identity provider as a trusted client in their Identity Provider (external IdP).
The federation server knows the username for a person in each application and presents that application with a token that says, "This person is domain\johndoe or firstname.lastname@example.org".
No password is required for the user to log in to each system. Because of the trust between the two systems, the target application accepts this token and authenticates the user.
Authenticate flow specifies the steps to complete an authentication process.
OAuth 2.0 flow in which an Authorization Code is returned from the Authorization Endpoint, some tokens are returned from the Authorization Endpoint, and others are returned from the Token Endpoint.
The primary extension that OpenID Connect makes to OAuth 2.0 to enable End-Users to be Authenticated is the ID Token data structure. The ID Token is a security token that contains Claims about the Authentication of an End-User by an Authorization Server when using a Client, and potentially other requested Claims. The ID Token is represented as a JSON Web Token (JWT).
Identity Provider (IdP)
The identity provider is responsible for providing identifiers for users. An Identity provider is a kind of provider that creates, maintains, and manages identity information and provides authentication.
Requesting identity information (aka claims) about a user, e.g. his name or email address is modeled as a scope in OpenID Connect. There is e.g. a scope called profile that includes first name, last name, preferred username, gender, profile picture and more. The current version of the Unit4 Identity Services does not support the profile scope.
The introspection endpoint enables holders of access tokens to request a set of metadata about an access token from the OpenID Connect Provider that issued the access token.
OAuth 2.0 flow in which all tokens are returned from the Authorization Endpoint and neither the Token Endpoint nor an Authorization Code are used.
A system that issues a set of claims. An Issuer Identifier is a case sensitive URL using the https scheme that contains scheme, host, and optionally, port number and path components and no query or fragment components.
JSON Web Tokens (Jwt) is an open, industry standard RFC 7519 method for representing claims securely between two parties.
Legged (2-legged, 3-legged, n-legged)
The number of legs used to describe an OAuth request typically refers to the number of parties involved, stages of interaction between a client and an authorization server, and number of parties (delegates) involved.
OpenID Providers have metadata describing their configuration. In order for an OpenID Client to utilize OpenID Connect services for an End-User, the Client needs to know where the OpenID Provider is. Once an OpenID Provider is identified, the endpoint and other configuration (metadata) information for that OP is retrieved from a well-known location as a JSON document.
Multi-tenancy is an architecture in which a single instance of a software application serves multiple customers.
String value used to associate a client session with an ID Token, and to mitigate replay attacks. The value is passed through unmodified from the Authentication Request to the ID Token. If present in the ID Token, Clients MUST verify that the nonce Claim Value is equal to the value of the nonce parameter sent in the Authentication Request. If present in the Authentication Request, Authorization Servers MUST include a nonce Claim in the ID Token with the Claim Value being the nonce value sent in the Authentication Request. Authorization Servers SHOULD perform no other processing on nonce values used. The nonce value is a case sensitive string.
The OAuth 2.0 framework enables a third-party app to obtain limited access to an HTTP service. Instead of using the resource owner’s credentials to access a protected resource, the client obtains an access token (which is a string denoting a specific scope, lifetime, and other access attributes). Access tokens are issued to third-party clients by an authorization server with the approval of the resource owner. For specification of the entire protocol see http://tools.ietf.org/html/rfc6749
The authorization server is responsible for managing authorizations and access grants. Authorization Service is responsible for accepting requests from the OAuth 2.0 clients for authorization and refresh tokens
Public client applications
Reference tokens (sometimes also called opaque tokens) are just identifiers for a token stored on the token service. The token service stores the contents of the token in some data store, associates it with an infeasible-to-guess id and passes the id back to the client. The recipient then needs to open a back-channel to the token service, send the token to a validation endpoint, and if valid, retrieves the contents as the response.
Refresh tokens are credentials used to obtain access tokens. Refresh tokens are issued to the client by the authorization server and are used to obtain a new access token when the current access token becomes invalid or expires.
Relying Party (RP)
OAuth 2.0 Client application requiring End-User Authentication and Claims from an OpenID Provider.
An entity capable of granting access to a protected resource. When the resource owner is a person, it is referred to as an end-user.
Resource scopes identify web APIs (also called resource servers) - you could have e.g. a scope named calendar that represents your calendar API.
The server hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens.
Security Assertion Markup Language 2.0 (SAML 2.0) is a version of the SAML standard for exchanging authentication and authorization data between security domains. SAML 2.0 is an XML-based protocol that uses security tokens containing assertions to pass information about a principal (usually an end user) between a SAML authority, that is, an identity provider, and a SAML consumer, that is, a service provider.
Scopes are identifiers for resources that a client wants to access. This identifier is sent to the Identity Server during an authentication or token request. By default every client is allowed to request tokens for every scope, but you can restrict that.
A scope secret is a shared value known to a resource server and U4IDS. The scope secret is used to validate a access token against the introspection endpoint. Scope secrets are generated and published by U4IDS.
Self-contained tokens are using a protected, time-limited data structure that contains metadata and claims to communicate the identity of the user or client over the wire. A popular format would be JSON Web Tokens (JWT). The recipient of a self-contained token can validate the token locally by checking the signature, expected issuer name and expected audience or scope.
Opaque value used to maintain state between the request and the callback. Typically, Cross-Site Request Forgery (CSRF, XSRF) mitigation is done by cryptographically binding the value of this parameter with a browser cookie.
Digital signing of tokens is to assure integrity of the token payload. By digital sign the token allows any tampering with the contents of the certificate to be easily detected.
Locally unique and never reassigned identifier within the Issuer for the End-User, which is intended to be consumed by the Client.
In the Identity Server a tenant is the customer/company or an actor who needs to point to a different Identity Provider.
Security tokens are used to prove one's identity electronically. It holds information about a user or a resource. The purpose of a token is that you do not have to share your credentials with a server. There are different types of tokens - id_token, access_token, refresh_token and reference_token. For more information see the chapter Tokens
Trust is the characteristic whereby one entity is willing to rely upon a second entity to execute a set of actions and/or to make a set of assertions about a set of principals and/or digital identities. In the general sense, trust derives from some relationship (typically a business or organizational relationship) between the entities. With respect to the assertions made by one entity to another, trust is commonly asserted by binding messages containing those assertions to a specific entity through the use of digital signatures and/or encryption.
Unit4 Id claim
unit4_id claim is a specific claim supported by U4IDS, the purpose of the claim is to act as a unique identifier for a user in the Unit4 eco-system.
Short for Unit4 Identity Services.
A user-agent is acting on behalf of a user, typically a browser.
An X.509 digital certificate is a signed data structure designed to send a public key to a receiving party. X.509 is an ITU-T standard for a public key infrastructure (PKI) and Privilege Management Infrastructure (PMI).
WS-Federation extends WS-Trust to provide a flexible Federated Identity architecture with clean separation between trust mechanisms, security token formats, and the protocol for obtaining tokens. This architecture enables a reusable security token service model and protocol to address the identity requirements of both web applications and web services in a variety of trust relationships.