Glossary

Audience

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

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 token

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.

Certificate

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.

Claim

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).

Claims-based identity

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.

Client

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.

Client secret

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.

Federation gateway

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).

Federation server

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 johndoe@example.com".
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.

Flow

Authenticate flow specifies the steps to complete an authentication process.

Hybrid flow

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.

ID token

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.

Identity scopes

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.

Introspection

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.

Implicit flow

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.

Issuer

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.

Jwt

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.

Metadata

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

Multi-tenancy is an architecture in which a single instance of a software application serves multiple customers.

Nonce

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.

OAuth 2

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

OpenID Connect

OpenID Connect is a simple identity layer on top of the OAuth 2.0 protocol. It allows clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner. OpenID Connect allows clients of all types, including Web-based, mobile, and JavaScript clients, to request and receive information about authenticated sessions and end-users. The specification suite is extensible, allowing participants to use optional features such as encryption of identity data, discovery of OpenID Providers, and session management when it makes sense for them.

Public client applications

Public clients are incapable of maintaining the confidentiality of the credentials. Clients are not able to securely store credentials. Public clients have two profiles: - User-agent-based application: Client code is downloaded from a web server and executes in a user-agent. JavaScript-based, client side web applications. - Native application: installed and executed on the device used by the resource owner, particularly mobile

Reference token

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 token

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.

Resource owner

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

Resource scopes identify web APIs (also called resource servers) - you could have e.g. a scope named calendar that represents your calendar API.

Resource server

The server hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens.

SAML2.0

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.

Scope

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.

Scope secret

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 token

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.

State

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.

Temporary Identity Provider

The Temporary Identity Provider functionality allows admin users to tag an Identity Provider as temporary using both IDS Powershell and IDS Portal. It manages the lifecycle of temporary Identity Providers automatically.

Token signing

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.

Subject identifier

Locally unique and never reassigned identifier within the Issuer for the End-User, which is intended to be consumed by the Client.

Tenant

In the Identity Server a tenant is the customer/company or an actor who needs to point to a different Identity Provider.

Token

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

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

The 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.

U4IDS

Short for Unit4 Identity Services.

User Agent

A user-agent is acting on behalf of a user, typically a browser.

X.509 Certificate

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

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.