Основные концепции

Перед началом работы с Авторизой рекомендуется ознакомиться с основными сущностями системы и связями между ними.

Основные сущности Authoriza:

1. Пользователь
2. Проект
3. Подключение
4. Профиль

Эти сущности определяют, кто проходит аутентификацию, к какому продукту относится пользователь, какое приложение или сервис использует Authoriza и какой идентификатор получает приложение.

1. Пользователь (User)

Пользователь — человек, который проходит аутентификацию в Авторизе.

Пользователь является глобальной сущностью платформы и может использовать несколько проектов.

Сам пользователь не является идентификатором, который приложение должно использовать для хранения своих данных. Для приложения идентификатором пользователя является идентификатор его профиля в соответствующем проекте.

Пользователь
     │
     ├── Профиль в Проекте A
     │
     └── Профиль в Проекте B

Это разделение позволяет использовать одну учетную запись в нескольких проектах, сохраняя изоляцию данных между ними.

2. Проект (Project)

Проект объединяет подключения, пользователей и настройки, относящиеся к одному продукту или сервису.

Проекты изолированы друг от друга.

Внутри одного проекта все подключения используют общую систему идентификации пользователей. Это позволяет реализовать единый вход (Single Sign-On, SSO) между несколькими приложениями одного проекта.

Например, один проект может объединять:

• основной веб-сайт;
• мобильное приложение;
• административную панель;
• API.

Проект
   │
   ├── Подключение: веб-приложение
   ├── Подключение: мобильное приложение
   ├── Подключение: административная панель
   └── Подключение: API

Проект является основной границей изоляции пользовательских данных.

Один и тот же пользователь может иметь профиль в нескольких проектах, но профиль одного проекта не предоставляется другому проекту.

3. Подключение (Connection)

Подключение — конфигурация конкретного приложения или сервиса, использующего Authoriza.

Подключение содержит параметры, необходимые для интеграции приложения с Авторизой, включая идентификатор клиента (Client ID), тип приложения и разрешенные Redirect URI.

Одному проекту может соответствовать несколько подключений.

Например:

Проект "Мой сервис"
     │
     ├── Подключение "Web"
     ├── Подключение "Mobile"
     └── Подключение "Admin"

Подключение относится только к одному проекту.

Подключения одного проекта используют общую систему идентификации пользователей проекта. Поэтому пользователь, успешно прошедший аутентификацию в одном подключении, может использовать SSO в других подключениях того же проекта, если соответствующий сценарий поддерживается приложением.

4. Профиль (Profile)

Профиль — представление пользователя внутри конкретного проекта.

Профиль создается в контексте проекта и принадлежит только одному проекту.

Пользователь
     │
     ├── Профиль в Проекте A
     │
     ├── Профиль в Проекте B
     │
     └── Профиль в Проекте C

Один пользователь может иметь не более одного профиля в конкретном проекте.

При этом один и тот же пользователь может иметь разные профили в разных проектах.

Профиль является границей идентичности пользователя для приложения внутри проекта.

Идентификатор профиля

Каждый профиль имеет уникальный идентификатор.

В OpenID Connect этот идентификатор используется как значение claim sub (subject) в ID Token.

Например:

{
  "sub": "4fb3e1af-6e34-4ef1-b4f0-0f2c2b2d6c65"
}

Значение sub идентифицирует пользователя в контексте проекта.

Приложение должно использовать sub как основной идентификатор пользователя в собственной бизнес-логике и базе данных.

Не следует использовать адрес электронной почты в качестве основного идентификатора пользователя. Email может измениться, тогда как идентификатор профиля предназначен для стабильной идентификации пользователя.

Важно: значение sub не следует рассматривать как глобальный идентификатор пользователя Authoriza. Один и тот же человек может иметь разные значения sub в разных проектах.

Изоляция пользователей между проектами

Проекты являются независимыми пространствами идентификации.

Например, один человек может использовать три сервиса:

                    Пользователь
                         │
          ┌──────────────┼──────────────┐
          │              │              │
          ▼              ▼              ▼
     Проект A        Проект B        Проект C
          │              │              │
       Profile A      Profile B      Profile C
          │              │              │
        sub=A          sub=B          sub=C

Каждый проект работает только со своим профилем.

Поэтому:

• Проект A не получает профиль пользователя из Проекта B.
• Проект B не получает профиль пользователя из Проекта C.
• Идентификаторы sub могут отличаться между проектами.
• Данные одного проекта не становятся автоматически доступными другому проекту.

Такая изоляция позволяет использовать одну учетную запись Authoriza для разных независимых сервисов без объединения их пользовательских данных.

Аутентификация и идентификация

Авториза выполняет аутентификацию пользователя и предоставляет приложению информацию, необходимую для его идентификации.

После успешной аутентификации приложение получает ID Token и, в зависимости от используемого потока и запрошенных scope, Access Token.

ID Token и Access Token содержат идентификатор аутентифицированного субъекта в claim sub.

Приложение использует этот идентификатор для определения того, какой локальной учетной записи соответствует пользователь.

Авторизация доступа к конкретным ресурсам приложения является отдельной задачей. Получение валидного ID Token или Access Token само по себе не означает, что пользователь имеет доступ ко всем ресурсам приложения.

Связи между сущностями

• Один Пользователь может иметь профили в нескольких Проектах.
• В одном Проекте один Пользователь имеет один Профиль.
• Каждый Профиль принадлежит только одному Проекту.
• Один Проект может иметь несколько Подключений.
• Каждое Подключение принадлежит только одному Проекту.
• Подключения одного Проекта используют общую систему идентификации пользователей.
• sub идентифицирует профиль пользователя в контексте проекта.
• sub не является глобальным идентификатором пользователя Authoriza.
• Проекты изолированы друг от друга.
• Авторизация доступа к ресурсам приложения определяется самим приложением.