Identity Access Management

Status Quo

Identity Access Management (IAM) is increasingly offered by providers as a service. Cloud-hosted IAM-services are refered to as Identity-as-a-Service(IdaaS).

Beside the storage of user identities IAM comprises the following topics:

• Multi-Factor-Authentication (MFA)
  well-known from 2FA that combines username/password and additional SMS text verification
• delegated authorization
  a Ressource-Client(eg. finance app) is authorized for (restricted) access on a Ressource-Server(eg. bank server) on behalf of the Ressource-Owner(eg. bank customer) without resp. password. The most commonly used protocol is oauth2.0
• Single-Sign-On (SSO)
  allows users to sign in once to an Authentication-Server in order to access other (web-)applications without additional password/credentials. It is increasingly common for a web portal (web service with personalized access) to offer authentication via a third-party identity platform in addition to the 'classic' login with on-premise account and password.  The most commonly used protocol is OpenIDConnect (that is based on oauth2.0)
• Self Souvereign Identity(SSI)
  holders/persons generate and control unique digital identities called Decentralized Identifiers(DID). The W3C DID Working Group is currently developing a (complex) standard.

Solutions based on oauth2.0/OIDC have in practice led to quasi-monopolies of Facebook & Google. Integration of an Auth-Server is a proprietary task for web-applications and as a prerequisite a user of a web-application that e.g. supports SSO must have an account with at least one integrated Auth-Server - and this is the case in many cases with Facebook & Google. While this saves customers from having to enter and manage different on-premises account/passwords, it also allows these third-party providers potentially unwanted insight into user behavior.

The identity platforms Verimi,, netID, ID4me and YES are to be understood as a European answer to the problem of not ceding identity on the net to US corporations without a fight. Smaller heterogenous identity platforms, which are not suspected of spying on user behaviour but are struggling with a lack of support from online portals, can therefore offer their customers little added value (Verimi is called a ''typisch deutscher Fehlstart''). Identity platforms try to profile themselves with additional functionalities, e. g. support for payment transactions, review of age restrictions.

In principle OAuth2.0 could be used for UNITED-PAGES. Each UNITED-PAGES webserver is a Resource-Server that Client-Applications access via an HTTP-API. Each UNITED-PAGES provider is a trusted email provider and could also provide an Authorization-Server for its users. However, each Authorization-Server would have to be initialized with each Resource-Server. This is not pragmatically feasible taking into account the distributed approach of UNITED PAGES.

SSI is an up-and-coming approach but there is a risk that complexity prevents a broad acceptance.

Based on pky-UNIT, UNITED-PAGES offers a much more elegant method for Authentication and Authorization.

oauth2.0 / OpenIdConnect(OIDC)

Since OpenID Connect (OIDC) has become the leading standard for single sign-on and identity provision on the Internet for web, browser-based and mobile APPs it deserves a closer look. OIDC is based on the OAuth2.0 authorization framework that is typically implemented using JSON Web Token (JWT).

JSON Web Token (JWT)

A JWT can be seen as an access key for HTTP-request to a web-service without the need to store something session-specific on the web service side (which fundamentally differentiates JWT from session cookies). In a JWT not only 'payload' is contained (Who was authorized/authenticated? For which service was the key issued? When was the key issued? How long is the key valid? ...), but also a digital signature that makes it impossible to manipulate the JWT. This signature was generated with a cryptographic 'secret key' that was previously exchanged during initialization between the generator of the JWT and the requested web-server(s).

OAuth2.0

OAuth2.0 is a protocol that is used for delegated authorization. A Client-Application uses a JWT that was generated from an Authentication-Server for API-access of protected resources (data) stored on a separate Resource-Server without having to know the credentials of the resource-owner. The Rescoure-Owner might not be identical with the user of the Client-Application, therefore it is called delegated authorization. OAuth2.0 is particularly advantageous when a web-service is implemented by different Resource-Servers e.g. when videos of a Resource-Owner are physically stored on a different Resource-Server than his requested audio files or PDF documents. In another well-known scenario, a Pinterest user wants to allow the Pinterest Client-Application access to the friends list on his own Facebook account. Here Facebook not only provides the Resource-Server where i.a. the friend lists are accessible via an API but also the Authentication-Server of Facebook is used.

In the initialization phase, various configuration data must be generated and exchanged between the Resource-Server(s), Authentication-Server(s) and Client-Application(s) (e.g. before your client-application can use Google's OAuth2.0 authentication system, you must set up a project in the Google API Console):

• the Authentication-Server and the Resource-Server must have set the same secret-key for encoding resp. decoding of JWT signatures
• the Authentication-Server and the Client-application must have set the same redirect-uri of the Client-Application
• the Resource-Server, the Client-Application and the Authentication-Server must have set the same client-id of the Client-Application
• the Authentication-Server must (optionally) have the branding information and access-right selection will be displayed on the user-consent dialog
• the Client-Application must have the authentication-URL of the Authentication-Server

An OAuth2.0-session then runs as follow:

• a user of the Client-Application starts with the selection of his preferred Authentication-Service-Provider (e.g. Google, Facebook)
• the Client-Application calls the authentication-URL of that Service (e.g. https://accounts.google.com/o/oauth2/v2/auth?scope=openid&redirect_uri=<client_callback_url>).
• the Authentication-Server opens a dialog where the credentials of the user-account at the Authentication-Server are requested (typically a recent prior verification spares this manual interaction)
• optionally the user can confirm a selection of specific access-rights for the Client-Application via an additional consent-dialog
• the Authentication-Server calls the redirect-URL of the Client-Application (parameterized with an authentication code i.e. <client_callback_url>?code=<authentication-code>) (Front-Channel)
• the Client-Application starts a further HTTP-POST-request (Back-Channel) to the Authentication-Server incl. the received authorization code in the HTTP-POST-body (Back-Channel)
• the Authentication-Server returns a signed JWT in the HTTP-POST-result
• the JWT can be used with further HTTP-requests from Client-Application to Resource-Server (in the Bearer) until expiration (a refresh is possible)
• each time the Ressource-Server decodes the signature of a received JWT and checks integrity

OpenID Connect (OIDC)

OIDC is an authentication layer on top of OAuth2.0, which allows clients to verify the identity of an end-user and obtain basic profile information about the end-user via a RESTful HTTP API. In addition to the Access- and Refresh-tokens known from OAuth2.0, the ID-token is specified and typically used during log-in.

Controversy

In addition to the above mentioned advantages, OAuth2.0 / OIDC also has enormous disadvantages that caused lead developers to leave the project. In the case of disputes, economic interests had been placed above security aspects. The standard is more like a complex framework, and for its safe implementation, developers need to have a high level of expertise. The biggest weakness is in the actual implementation. Google and Facebook dominate the market for Authentication-Servers. The main reason for this lies in the fact that on the part of the Client-Applications and Resource-Servers, the support of a supported Authentication-Server always requires individual effort.

In principle OAuth2.0 could be used for UNITED-PAGES. Each UNITED-PAGES webserver is a Resource-Server that Client-Applications access via an HTTP-API. Each UNITED PAGES provider is a trusted email provider and could also provide an Authorization-Server for its users. However, each Authorization-Server would have to be initialized with each Resource-Server. This is not pragmatically feasible taking into account the distributed approach of UNITED PAGES.

Based on pky-UNIT, UNITED-PAGES offers a much more elegant method for Authentication and Authorization.

UNITED-PAGES

Login via Browser

If the user of the web portal chooses the login option via UNITED-PAGES (after entering his/her email address), he/she is redirected to the login page of his/her PROVIDER. After a correct login, the WEBSERVER automatically creates a token-UNIT and calls up the web-portal with the e-mail address and token-URI. The web-portal can identify the responsible PROVIDER from the email address and can validate the token by means of a GET request.

Login via Applikation

Security

Advantages

For users, it is more obvious to use an identity platform that is also encountered in other situations (e.g. Facebook, Google, UNITED-PAGES), instead of dealing with a new identity platform, which was created for this purpose alone - and requires a separate registration. Compared to (US) 'data hydras' which are controversial from a data protection point of view, UNITED-PAGES has an advantage because of the free choice of a PROVIDER.