Authentication

		|Authentication generally refers to a set of processes which result in a resource server (in this case, OBP-API) knowing about the User and/or Application that is making the http request it receives.

| |In most cases when we talk about authentication we are thinking about User authentication, e.g. the user J.Brown is requesting data from the API. |However, user authentication is pretty much always accompanied by knowledge of the Client AKA Consumer, TPP or Application. |In some cases, we only perform Client authentication which results in knowledge of the Application but not the human that is making the call. This is useful when we want to protect the identity of a user but still want to control access to the API. | |In most cases, OBP-API server knows about at least two entities involved in the http request / call: The Client and the User - but it will also know about (and trust) the Identity Server (Provider) that authenticated the user and other elements in the chain of trust such as load balancers and certificate authorities. | |In simple terms, there are two phases of the Authentication process: | |1) The phase where an authorisation token is obtained. |2) The phase where an authorisation token is used. | |Phase 1 is an exchange of credentials such as a username and password and possibly knowledge of a "second factor" for a token. | |Phase 2 is the execution of an http call which contains the token in a "header" in exchange for some response data or some resource being created, update or deleted. | |There are several methods of obtaining and using a token which vary in their ease of use and security. | |Direct Login is built into OBP and used for testing purposes / local installations. | |OAuth2 / Open ID Connect (OIDC) is the recommended method for production use, and depends on the configuration of Identity Provider solutions such as Keycloak or OBP-OIDC or external services such as Google or Yahoo. | |Open Bank Project can support multiple identity providers per OBP instance. For example, for a single OBP installation, some Users could authenticate against Google and some could authenticate against a local identity provider. |In the cases where multiple identity providers are configured, OBP differentiates between Users by not only their Username but also by their "Identity Provider". i.e. J.Brown logged in via Google is distinct from J.Brown who logged in via a local OBP instance. | |Phase 1 generally results in a temporary token i.e. a token that is valid for a limited amount of time e.g. 2 hours or 3 minutes. | |Phase 1 might also result in a token that represents a subset of the User's full permissions. This token is generally called a Consent. i.e. a User might give consent for an application to access one of her accounts but not all of them. A Consent is generally given to a Client and bound to that Client i.e. no other application may use it. | |Phase 2 results in OBP having identified a User record in the OBP database so that Authorisation can proceed. |