This page provides some key concepts for reference.
Access tokens are credentials used to access protected resources. An Access token is a string representing an authorization issued to the Client. The access token provides an abstraction layer, replacing different authorization constructs, such as user name and password, with a single token understood by the resource server.
An App is a representation of an application. An App belongs to a Team. An App declares which Solutions it is going to use. Each App has a unique AppKey that is used to identify the App when an API is called, and the AppKey is shared among the developers in the Team. An AppKey is required in order to access services in the Developer Portal. Each App may have one or more Clients. Apps and Teams are available under the MY APPS section in the Developer Portal. Refer to Managing your Apps in Developer Portal for more information.
An AppKey, also known as Consumer Key, is required to access Defli APIs and is passed as part of the header of the HTTP requests to services. The AppKey is automatically generated when an App is created and listed in the App details Keys panel.
To generate the required header for the "Try it out" feature of Developer Portal, click the "Authorize" button on the right-top side of the API documentation (aka swagger doc) to open a dialog box which is automatically populated with Bearer token and the AppKey. The token is generated based on your credentials and the AppKey of the first App of the Team. If the AppKey field is blank, it means that the first App is not authorized for the use of the service that you want to try out. In such cases, you can paste the AppKey of the App you want in the field. Click Save to use the generated token and AppKey. Note: You must do this each time you view a new API documentation section.
The AppKey is also used to track your App when an API is accessed and could be used for billing purposes if the underlying service is monetized by consumption.
Do not share the AppKey with other developers outside your Team. It is OK for AppKeys to be exposed in client side javascript code.
By using the Delfi APIs, programmatically or using Developer Portal, you agree to use only AppKeys assigned to your Team and in certain situations to your organization or company. Using AppKeys not assigned to you is a violation of the terms and conditions of Developer Portal usage.
Authentication is the process of verifying your identity when you provide your user name and password.
Authorization is the act of granting an authenticated party permission to do something. It specifies what data you are allowed to access and what you can do with that data.
An Authorization code is a short lived Token provided to a Client application by the authorization endpoint as part of the "authorization code" flow, one of the four OAuth2 authorization grants. The code is returned to the Client application in response to the authentication of a resource owner, indicating the resource owner has delegated authorization to access the requested resources. As part of the flow, the code is later redeemed for an Access token. (Microsoft identity platform developer glossary)
The OAuth 2.0 specification defines four grant types: authorization code, implicit, resource owner password credentials, and Client credentials. The credential returned to the Client is either an Access token or an authorization code (exchanged later for Access tokens), depending on the type of authorization grant used.
A security token contains claims, which provide assertions about one entity, such as a Client application or resource owner, to another entity, such as the resource server. Claims are name/value pairs that relay facts about the token subject, such as:
- Security Token Server that generated the token.
- Date when the token was generated.
- Subject, such as the user--except for daemons.
- Audience, which is the app for which the token was generated.
- App (the Client) that asked for the token. In the case of web apps, this app might be the same as the audience.
A Client is an application that makes protected resource requests on behalf of the resource owner. The term "Client" does not imply any particular hardware implementation characteristics or, for instance, whether the application executes on a server, a desktop, or other device. (OAuth2 Authorization Framework)
The OAuth2 Authorization Framework defines two types of Clients, "confidential" and "public", based on the Client's ability to maintain the confidentiality of its credentials. Applications can implement a web Client (confidential) which runs on a web server, a native Client (public) installed on a device, or a user-agent-based Client (public) which runs in a device's browser. (Microsoft identity platform developer glossary)
These are Clients that are capable of maintaining the confidentiality of their credentials, for example a Client implemented on a secure server with restricted access to the Client credentials, or clients that are capable of secure Client authentication using other means.
Deprecated features or services are scheduled to be retired in the future.
All support and engineering investment stops when features or services reach end-of-life.
Retired features or services are no longer supported. Customers may purchase paid programs for extended support to cover maintenance for as-is features or services (if available) until the feature or service reaches end-of-life.
ID tokens are security tokens granted by the OpenID Provider that contains information about an end user and sent to the Client application as part of an OpenID Connect flow. They can be sent alongside or instead of an Access token. ID tokens are used by the Client to authenticate the user.
OAuth 2.0 is the industry-standard protocol for authorization. It is a delegated authorization framework that enables apps to obtain limited access (scopes) to a resource owner’s data without giving away a user name and password.
OpenID Connect is a simple identity layer on top of the OAuth 2.0 [RFC6749] protocol. It enables 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 extends OAuth 2.0 and adds an ID token that is a simple Json Web Tokens (JWT), that can be obtained using flows conforming to the OAuth 2.0 specifications.
A public Client is incapable of maintaining the confidentiality of its credentials, for example a Client that executes on the device used by the resource owner or an installed native application or a web browser-based application, and is incapable of secure Client authentication via any other means.
efresh 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.
Retirement is the end of the availability and support of a feature or service. The feature or service is unavailable to customers as engineering investment has stopped. Customers may purchase extended support in some cases, at the discretion of SLB, to continue usage until end-of-life.
A Service is a microservice exposed to developers through one or more API endpoints.
Solutions comprise of set of services, individual or group of services, that provide coherent functionality to applications. Apps should be authorized to use a Solutions when created. Most of services included in a Solution are automatically approved but some might require explicit approval.
A Team is a set of developers in the same billing account that jointly develop an application. Each App belongs to a Team. Apps and Teams are available from MY APPS in the Developer Portal.
A Token is a data structure that contains information about the issuer and claims. It is signed and usually has an expiration time. Json Web Tokens (JWT) are a widely used format for tokens. For an OAuth2 authorization grant, the token types include access token, refresh token, and ID Token.