Skip to main content

OIDC

OpenID Connect (OIDC) - протокол аутентификации. Позволяет third-party приложениям проверить подленность "identity" пользователя и получения информации о нем (profile information).

OIDC использует JWTs для обмена идентификационной информацией, которые можно получить соответствующими flows из OAuth 2.0. OIDC идентификационный слой построенный поверх OAuth 2.0 фреймворка.

OIDC позволяет пользователям аутентифицироваться с помощью стороннего Identity Provider (IdP). IdP аутентифицирует пользователя и отправляет обратно приложению идентификационный токен, который может быть использован для проверки личности пользователя.

OIDC поддерживает единый вход Single Sign-On.

OIDC обратно совместим с OAuth 2.0.

OpenID vs. OAuth2​

OAuth 2.0 - шаринг ресурсов. Авторизация. Доступ к ресурсам.

OIDC - аутентификация пользователей. Его цель - предоставить один логин для входа на несколько приложений.

Flows​

Подход к проведению аутентификации будет зависеть как и в OAuth от того умеет ли клиент хранить секреты и есть ли у него backend.

Authorization Code​

IdP возвращает authorization code клиенту. По authorization code можно получить ID Token и Access Token. Применим для клиентов, которые могут безопасно хранить секреты.

Шаги аутентификации​

  • Клиент подготавливает запрос на аутентификацию, содержащий требуемые параметры запроса.
  • Клиент отправляет запрос на Сервер авторизации.
  • Сервер авторизации выполняет аутентификацию Конечного пользователя.
  • Сервер авторизации получает согласие/авторизацию конечного пользователя.
  • Сервер авторизации отправляет Конечного пользователя обратно Клиенту с кодом авторизации.
  • Клиент запрашивает ответ, используя код авторизации в Token Endpoint.
  • Клиент получает ответ, содержащий ID Token и Access Token в тексте ответа.
  • Клиент проверяет ID Token и извлекает идентификатор субъекта конечного пользователя.

Запрос на аутентификацию​

Запрос содержит параметры

  • scope - openid scope value
  • response_type - code
  • client_id - OAuth 2.0 Client Identifier
  • redirect_uri - Redirection URI
  • state - Cross-Site Request Forgery (CSRF, XSRF)

etc..., more here

Examples​

auth request
  HTTP/1.1 302 Found
  Location: https://server.example.com/authorize?
    response_type=code
    &scope=openid%20profile%20email
    &client_id=s6BhdRkqt3
    &state=af0ifjsldkj
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
auth response
  HTTP/1.1 302 Found
  Location: https://client.example.org/cb?
    code=SplxlOBeZQQYbYS6WxSbIA
    &state=af0ifjsldkj
auth error response
  HTTP/1.1 302 Found
  Location: https://client.example.org/cb?
    error=invalid_request
    &error_description=Unsupported%20response_type%20value
    &state=af0ifjsldkj
Token Request
  POST /token HTTP/1.1
  Host: server.example.com
  Content-Type: application/x-www-form-urlencoded
  Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW

  grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
Successful Token Response
  HTTP/1.1 200 OK
  Content-Type: application/json
  Cache-Control: no-store

  {
   "access_token": "SlAV32hkKG",
   "token_type": "Bearer",
   "refresh_token": "8xLOxBtZp8",
   "expires_in": 3600,
   "id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6IjFlOWdkazcifQ.ewogImlzc
     yI6ICJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tIiwKICJzdWIiOiAiMjQ4Mjg5
     NzYxMDAxIiwKICJhdWQiOiAiczZCaGRSa3F0MyIsCiAibm9uY2UiOiAibi0wUzZ
     fV3pBMk1qIiwKICJleHAiOiAxMzExMjgxOTcwLAogImlhdCI6IDEzMTEyODA5Nz
     AKfQ.ggW8hZ1EuVLuxNuuIJKX_V8a_OMXzR0EHR9R6jgdqrOOF4daGU96Sr_P6q
     Jp6IcmD3HP99Obi1PRs-cwh3LO-p146waJ8IhehcwL7F09JdijmBqkvPeB2T9CJ
     NqeGpe-gccMg4vfKjkM8FcGvnzZUN4_KSP0aAp1tOJ1zZwgjxqGByKHiOtX7Tpd
     QyHE5lcMiKPXfEIQILVq0pc_E2DzL7emopWoaoZTF_m0_N0YzFC6g6EJbOEoRoS
     K5hoDalrcvRYLSrQAZZKflyuVCyixEoV9GfNQC3_osjzw2PAithfubEEBLuVVk4
     XUVrWOLrLl0nx7RkKU8NXNHq-rvKMzqg"
  }

Implicit​

При использовании Implicit Flow все токены возвращаются из Authorization Endpoint. Применим для браузеров, на скриптовых языках, без backend.

Шаги аутентификации​

  • Клиент подготавливает запрос на аутентификацию, содержащий требуемые параметры запроса.
  • Клиент отправляет запрос на Сервер авторизации.
  • Сервер авторизации выполняет аутентификацию Конечного пользователя.
  • Сервер авторизации получает согласие/авторизацию конечного пользователя.
  • Сервер авторизации отправляет Конечного пользователя обратно Клиенту с ID Token и, при необходимости, с Access Token.
  • Клиент проверяет ID Token и получает идентификатор субъекта конечного пользователя.

Запрос на аутентификацию​

Аналогично Authorization Code.

  • response_type - id_token token or id_token

etc..., more here

Examples​

Authentication Request
  GET /authorize?
    response_type=id_token%20token
    &client_id=s6BhdRkqt3
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
    &scope=openid%20profile
    &state=af0ifjsldkj
    &nonce=n-0S6_WzA2Mj HTTP/1.1
  Host: server.example.com
Successful Authentication Response
  HTTP/1.1 302 Found
  Location: https://client.example.org/cb#
    access_token=SlAV32hkKG
    &token_type=bearer
    &id_token=eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso
    &expires_in=3600
    &state=af0ifjsldkj

Hybrid Flow​

Совмещенный режим. Некоторые токены возвращаются сразу в Authorization Endpoint, некоторые в Token Endpoint.

Шаги аутентификации​

  • Клиент подготавливает запрос на аутентификацию, содержащий требуемые параметры запроса.
  • Клиент отправляет запрос на Сервер авторизации.
  • Сервер авторизации выполняет аутентификацию Конечного пользователя.
  • Сервер авторизации получает согласие/авторизацию конечного пользователя.
  • Сервер авторизации отправляет конечного пользователя обратно Клиенту с Кодом авторизации и, в зависимости от типа ответа, одним или несколькими дополнительными параметрами.
  • Клиент запрашивает ответ, используя код авторизации в Token Endpoint.
  • Клиент получает ответ, содержащий ID Token и Access Token в теле ответа.
  • Клиент проверяет ID Token и извлекает идентификатор субъекта конечного пользователя.

Запрос на аутентификацию​

Аналогично Authorization Code.

  • response_type - code id_token, code token, or code id_token token

etc..., more here

Examples​

Authentication Request
  GET /authorize?
    response_type=code%20id_token
    &client_id=s6BhdRkqt3
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
    &scope=openid%20profile%20email
    &nonce=n-0S6_WzA2Mj
    &state=af0ifjsldkj HTTP/1.1
  Host: server.example.com
Successful Authentication Response
  HTTP/1.1 302 Found
  Location: https://client.example.org/cb#
    code=SplxlOBeZQQYbYS6WxSbIA
    &id_token=eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso
    &state=af0ifjsldkj

Endpoints​

UserInfo Endpoint​

The UserInfo Endpoint is an OAuth 2.0 Protected Resource that returns Claims about the authenticated End-User.

UserInfo Request
  GET /userinfo HTTP/1.1
  Host: server.example.com
  Authorization: Bearer SlAV32hkKG

Authorization: Bearer <Access Token>

Successful UserInfo Response
  HTTP/1.1 200 OK
  Content-Type: application/json

  {
   "sub": "248289761001",
   "name": "Jane Doe",
   "given_name": "Jane",
   "family_name": "Doe",
   "preferred_username": "j.doe",
   "email": "janedoe@example.com",
   "picture": "http://example.com/janedoe/me.jpg"
  }

Tokens​

ID Token​

ID Token - это токен безопасности, который содержит утверждения об аутентификации конечного пользователя Сервером авторизации при использовании Клиента и, возможно, другие запрашиваемые утверждения.

ID Token
  {
   "iss": "https://server.example.com",
   "sub": "24400320",
   "aud": "s6BhdRkqt3",
   "nonce": "n-0S6_WzA2Mj",
   "exp": 1311281970,
   "iat": 1311280970,
   "auth_time": 1311280969,
   "acr": "urn:mace:incommon:iap:silver"
  }
  • sub - Subject Identifier. A locally unique and never reassigned identifier within the Issuer for the End-User

ID Tokens MAY contain other Claims.

Access Token​

Аналогично OAuth 2.0. Токен доступа к ресурсам, авторизации.

Refresh Token​

grant_type value refresh_token

Refresh Request
POST /token HTTP/1.1
  Host: server.example.com
  Content-Type: application/x-www-form-urlencoded

  client_id=s6BhdRkqt3
    &client_secret=some_secret12345
    &grant_type=refresh_token
    &refresh_token=8xLOxBtZp8
    &scope=openid%20profile
Successful Refresh Response
  HTTP/1.1 200 OK
  Content-Type: application/json
  Cache-Control: no-store

  {
   "access_token": "TlBN45jURg",
   "token_type": "Bearer",
   "refresh_token": "9yNOxJtZa5",
   "expires_in": 3600
  }

openid scope value​

Scopes ассоциированы с Access Token и определяют какие ресурсы может получить клиент.

OpenID Connect, scopes определяют какую информацию о пользователе (какие claims) может получить клиент:

  • profile - default profile Claims: name, family_name, given_name, middle_name, nickname, preferred_username, profile, picture, website, gender, birthdate, zoneinfo, locale, and updated_at
  • email - email and email_verified Claims
  • address - address Claim
  • phone - phone_number and phone_number_verified Claims
example
scope=openid profile email phone

Claims​

OIDC использует JWT, которые содержат claims. Сlaims - утверждения о пользователе такие как имя, email, etc...

  • sub - Subject - Identifier for the End-User at the Issuer.
  • name - End-User's full name in displayable form including all name parts, possibly including titles and suffixes, ordered according to the End-User's locale and preferences.
  • picture - an image
  • phone_number
  • address
  • updated_at

etc...

Links & Docs​

OpenID Connect Core 1.0 incorporating errata set 2
Standard Claims