OIDC срещу OAuth 2.0:

Аналогия:

OAuth 2.0 е като ключ за хотелска стая - дава достъп до стаята, но не казва кой сте.

OpenID Connect е като лична карта - доказва кой сте и предоставя основна информация за вас.

Основни понятия в OIDC:

• End User (Краен потребител) - Потребителят, който се удостоверява и дава достъп до своите данни
• Relying Party (RP) / Client - Приложението, което иска да удостоверява потребителя и да получава информация за него
• OpenID Provider (OP) - Сервърът, който удостоверява потребителя и предоставя ID Token
• ID Token - JWT token, който съдържа claims за удостоверявания потребител
• UserInfo Endpoint - API endpoint, който връща допълнителна информация за потребителя
• Claims - Твърдения за потребителя (име, имейл, снимка и т.н.)

OIDC Authorization Code Flow:

1. 1

   Authentication Request

   Клиентът пренасочва потребителя към OP с OIDC параметри

2. 2

   User Authentication

   Потребителят се удостоверява при OpenID Provider

3. 3

   Authorization Response

   OP пренасочва обратно с authorization code

4. 4

   Token Request

   Клиентът изпраща authorization code за tokens

5. 5

   Token Response

   OP връща ID Token, Access Token и опционално Refresh Token

6. 6

   UserInfo Request

   Клиентът използва Access Token за UserInfo endpoint

7. 7

   UserInfo Response

   OP връща информация за потребителя

Стандартни Claims в OIDC:

Идентификационни Claims

• sub - Subject - уникален идентификатор на потребителя
• iss - Issuer - идентификатор на OpenID Provider
• aud - Audience - за кого е предназначен token-а
• exp - Expiration time
• iat - Issued at

Profile Claims

• name - Пълно име
• given_name - Собствено име
• family_name - Фамилно име
• middle_name - Презиме
• nickname - Псевдоним
• preferred_username - Предпочитано потребителско име
• profile - URL към профилна страница
• picture - URL към профилна снимка
• website - URL към личен уебсайт
• gender - Пол
• birthdate - Дата на раждане
• zoneinfo - Time zone
• locale - Локализация
• updated_at - Кога е обновен профила

Email Claims

• email - Имейл адрес
• email_verified - Дали имейлът е верифициран

Phone Claims

• phone_number - Телефонен номер
• phone_number_verified - Дали номерът е верифициран

Address Claims

• address - Адресна информация

OIDC Scopes (Обхвати):

• openid - Задължителен - индикира, че това е OIDC заявка, не OAuth
• profile - Достъп до основни профилни claims (name, family_name, picture и т.н.)
• email - Достъп до email и email_verified claims
• address - Достъп до address claim
• phone - Достъп до phone_number и phone_number_verified claims
• offline_access - Заявява refresh token за дълготраен достъп

OIDC Endpoints:

• Authorization Endpoint - Започва OIDC flow и удостоверява потребителя
• Token Endpoint - Обменя authorization code за tokens
• UserInfo Endpoint - Връща claims за удостоверения потребител
• Discovery Endpoint - OIDC конфигурация
• JWKS Endpoint - JSON Web Key Set за валидиране на signatures
• End Session Endpoint - Затваря сесията на потребителя

OIDC Discovery Document:

OpenID Providers публикуват конфигурационен документ, който описва техните endpoints и поддържани функции.

Популярни OpenID Providers:

• Google - https://accounts.google.com/.well-known/openid-configuration
• Microsoft - https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration
• Auth0 - https://your-domain.auth0.com/.well-known/openid-configuration
• Okta - https://your-domain.okta.com/.well-known/openid-configuration
• GitHub - https://github.com/login/oauth/authorize
• Keycloak - https://your-keycloak.com/auth/realms/your-realm/.well-known/openid-configuration

Сигурностни добри практики:

• Валидирайте ID Token - Проверявайте signature с JWKS endpoint
• Използвайте PKCE - За всички публични клиенти използвайте Proof Key for Code Exchange
• HTTPS винаги - Използвайте HTTPS за всички комуникации
• Ограничете scopes - Поисквайте само необходимите scopes за вашето приложение
• Ограничете времето на токените - Използвайте кратки access tokens и secure refresh tokens

Предимства на OpenID Connect: