Identity Access Management (IAM)

Procedure

In the following example, Alice (alice@a-provider.com) logs in to a SERVICE (x-service.com) via UNITED-PAGES. For better readability, curly braces {} are used (e.g., {https://www.x-service.com/home.html} instead of URL-encoded https:%2F%2Fwww.x-service.com%2Fhome.html).

Requirements

The implementation is simple and requires no error-prone libraries.

USER

• The user must be registered with the same email address with both the respective SERVICE and their PROVIDER

SERVICE

• login page must offer a "Login via UNITED-PAGES" button
• callback URL must support the parameters _cb, _email, and _session
• REST API must send the DELETE request to the PROVIDER and evaluate the returned status-code

PROVIDER

• login-page-URL must support the parameters _cb and _email
• REST API must receive and evaluate the DELETE request from the SERVICE for TOKEN

Security

Attack attempts are also taken into account.

Bypass Login

A TOKEN can only be generated indirectly by the user via login to the PROVIDER. The API does not support PUT/POST for TOKEN.

Man-In-The-Middle

A URL query is not encrypted and can, in principle, be intercepted. However, the data cannot be reused because the corresponding TOKEN is deleted by the requested SERVICE during the login process. If the service is temporarily unavailable, the TOKEN expires (recommended after 10 seconds).

Malicious SERVICE

A malicious SERVICE could offer a login process via UNITED-PAGES, but then not delete the corresponding TOKEN when its own callback URL is called. The corresponding TOKEN is unusable for logging into another service, as it contains the callback URL that allows each SERVICE to identify whether a TOKEN has been assigned to it.

A malicious SERVICE could initiate the generation of a TOKEN by specifying the callback URL of another SERVICE. The user would thus be misled but the TOKEN would be deleted anyway, and the malicious SERVICE would have no way of using it beforehand, as it would not know the session ID.