Skip to main content

Introduction

OpenID Connect

This document describes our OAuth 2.0 APIs implementation used for authentication and authorization purposes using as Identity Provider a claim based SSI protocol. These OAuth 2.0 APIs are also completely conforming to the OpenID Connect specification.

Setting up OAuth 2.0

Before your application can use RP's OAuth 2.0 authentication system for user login, you must set up a project in the RP API Console to obtain OAuth 2.0 credentials, set a redirect URI, and customize the branding information that your users see on the user-consent screen. You can also use the RP API Console to create a service account, enable billing, set up filtering, and do other tasks.

Obtain OAuth 2.0 credentials

You need OAuth 2.0 credentials, including a client ID and client secret, to authenticate users and gain access to RP's APIs. To require the client ID and client secret for a given OAuth 2.0 credential, make next query:

curl --location --request POST 'https://oauth2-cl.dizme.io/v2.0/intra-backoffice/client' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--header 'X-Auth-Token: authToken' \
--header 'X-Dizme-Agent-Id: DAPI' \
--data-urlencode 'redirect_url=https://example.com/backfromdizme/' \
--data-urlencode 'scope=openid' \
--data-urlencode 'domain=example.com' \
--data-urlencode 'img_url=https://example.com/logo.png'

Note: X-Auth-Token and X-Dizme-Agent-Id are required only if you try accessing services outside.

  • redirect_url - is a url address where customer will be redirected once auth complete
  • scope - openid which is a mandatory, than on of possible scopes email and phone, scopes must be separated by space. See info in Scopes section.
  • domain - domain address of required service, should be the same as redirect
  • img_url - logo for customization page, must be jpg, jpe or png

This query will return json with your client_id and client_secret

{
  "status_code": "SUCCESS",
  "message_code": "SUCCESS",
  "payload": {
    "client_id": "2a9ead06-f829-43ea-9e8e-39bc62be3b00",
    "secret": "MrjhTVGFf70rmRpcQyEgZnMco4IobVK-"
  }
}

Authenticating the user

Authenticating the user involves obtaining an ID token and validating it. ID tokens are a standardized feature of OpenID Connect designed for use in sharing identity assertions on the Internet.

The most commonly used approaches for authenticating a user and obtaining an ID token are called the "server" flow and the "implicit" flow. The server flow allows the back-end server of an application to verify the identity of the person using a browser or mobile device. The implicit flow is used when a client-side application (typically a JavaScript app running in the browser) needs to access APIs directly instead of via its back-end server.

This document describes how to perform the server flow for authenticating the user. The implicit flow is significantly more complicated because of security risks in handling and using tokens on the client side.

Back to top