Ликбез по OpenID Connect

1. OAuth 2.0 - это платформа (framework) авторизации, не аутентификации.

2. OpenID Connect (OIDC) - это платформа (framework) аутентификации и авторизации. Авторизация построена на базе OAuth 2.0. Не путать просто с OpenID 1.0, который только аутентификация.

Client_id/client_secret - это client credentials flow из OAuth 2.0. Используется для авторизации s2s (server-to-server).

Для авторизации кожаных мешков используется authorization code flow, client_id всегда используется, если нет client_secret, то клиент публичный, если client_secret есть, тогда клиент приватный и появляется шаг с аутентификацией клиента.

OAuth 2.0 - авторизация
OIDC - аутентификация и авторизация. Авторизация на OAuth 2.0.
Client_id/client_secret - client credentials flow из OAuth 2.0 для авторизации s2s (server-to-server).
Для кожаных мешков authorization code flow

Спасибо.

client_id всегда используется,
если нет client_secret, то клиент публичный, если client_secret есть, тогда клиент приватный и появляется шаг с аутентификацией клиента.

Может ли один и тот же client_id использоваться и для authorization code flow с публичным клиентом, и для s2s с секретом? Сервер Keycloak.

Может ли один и тот же client_id использоваться и для authorization code flow с публичным клиентом, и для s2s с секретом? Сервер Keycloak.

Нет. Клиент может быть либо только публичный, либо только приватный.

Клиент может быть либо только публичный, либо только приватный.

Спасибо!

по тупому - authorization_code для браузера, client_credentials для обмена между программами

все 5 типов авторизации с большим кол-вом не нужных слов:

Authorization code (authorization_code) — этот flow основан на редиректах. Клиент должен уметь взаимодействовать с user-agent-ом (обычно браузером) и обеспечивать клиент-серверное взаимодействие. Следовательно, этот flow подходит только для confidential клиентов. Его мы рассмотрим подробнее чуть позже.

Client credentials (client_credentials) — этот flow подходит только для Machine-to-Machine (M2M) приложений (кроны, CLis, backend сервисы). Напоминает «обычную» авторизацию, которая выполняется на основе client_id и client_secret: по сути, логин и пароль, в случае пользователя. Клиент выполняет запрос на сервер авторизации с client_id и client_secret и в ответ получает access token для доступа к запрашиваемому ресурсу.

Implicit — ненужно.

Resource owner password credentials - deprecated

Device authorization — для всякого странного.

ну и вообще для простого ознакомления подойдёт это https://habr.com/ru/companies/banki/articles/862516/

На мой взгляд Resource owner password credentials ближе всего к «обычной» авторизации, т.к. передатся именно пользовательские credentials, а не app credentials, в отличие от client_credentials flow.

Device authorization - это как authorization_code flow, но для ситуаций, когда клиентский app не может взаимодействовать с веб-браузером, однако веб-браузер можно открыть на другом устройстве пройти аутентификацию там.

https://habr.com/ru/companies/banki/articles/862516/

Как раз пример широкого и узкого. И аббревиатуры употребляются раньше, чем даются их определения.

Может ли для M2M и native application использоваться один Client ID? Если не один, как должны различаться свойства создаваемых пользователей?

Может ли для M2M и native application использоваться один Client ID?

Теоретически да, но зачем. Гораздо лучше разделить.

Если не один, как должны различаться свойства создаваемых пользователей?

Очевидно же, один для работы через браузер, другой для работы другого приложения. У них всё разное, время протухания токенов, поддержка refresh_token и т.д. и т.п. Между ними, на самом деле, вообще мало общего мало общего.

Что-то типа такого

    ns-job:
      client-id: ns-job
      client-name: ns-job
      secret: "{noop}zzzzzzz"
      method: client_secret_basic
      grant-types:
        - client_credentials
      token:
        format: reference
        accessTimeToLive: 30
        refreshTimeToLive: 120
        codeTimeToLive: 30
        reuseRefresh: false
      scopes:
        - read
        - write
        - admin

    browser-client:
      client-id: browser-client
      client-name: browser-client
      secret: "{noop}cccccc"
      method: client_secret_basic
      grant-types:
        - authorization_code
        - refresh_token
      uris:
        - http://xxx:8100/yyy/auth/authorized
      token:
        format: reference
        accessTimeToLive: 30
        refreshTimeToLive: 120
        codeTimeToLive: 30
        reuseRefresh: false
      scopes:
        - read
        - write

Точнее, так как OpenID дохнет в мае, FAS переходит на OIDC.

ma1uta, vtVitus, MirandaUser2, mx__, вопрос по JWT в Keycloak. Я правильно понимаю, что токен получают по адресу «token service»? Какие настройки менять, если по этому адресу выдаёт «Page not found»?

Как там в кейклоке хз (вообще это монстр и к нему лучше подходить после того как ты уже +- знаешь чего и как делать), но по стандарту вроде как идет для rest (браузера)

POST /oauth2/token

с параметрами аля

grant_type: authorization_code
code: fdgWpzMxmHo3aEaO22Mc5iT2WacTZ3GJhDpx0cnxgG7J87Pt264e03Q5oMeoF-K8nFfPdVkQGpUrNCVuuKHsGCyaoJY4EyK3R6ekfGieQwI3SL93a1rl8gwDjepMh3vH
redirect_uri: http://адрес_куда_вернуться/oauth2
client_id: browser

он тебе возвращает аля

access_token: "qmStCCYWFRQ1NHhHFjjw0S4gl6LCt6uZldmtocRmtNHUpR_yxL3FalFK6sBTsXvVPxqVINHFU88gBpcLbcY-EeHh_qclnLBwl9MUa5AuQD24WBjK1SNbPgQoYJr6OTTR"
expires_in: 215999
refresh_token: "1q7obKS_sEzfNUSFxTmPdjkYhgeL-bvISD-dziwDaa6QbJe8WydAiAscxIvpvwFtfmoWvaU6ttAN5V6VXHGyekHxyHH79VXWxY-yMeLxLS16hpGpkQceAIcSgPG8wlzU"
scope: "read admin write"
token_type: "Bearer"

Ну и дальше вызываешь

POST /oauth2/token-info

с параметром токена

token: qmStCCYWFRQ1NHhHFjjw0S4gl6LCt6uZldmtocRmtNHUpR_yxL3FalFK6sBTsXvVPxqVINHFU88gBpcLbcY-EeHh_qclnLBwl9MUa5AuQD24WBjK1SNbPgQoYJr6OTTR

ну и получаешь всю подноготную.

Тут https://habr.com/ru/articles/737548/ не плохо с нуля построение авторизации через oAuth2 и серверная часть и часть js и ресурсная.

Сделай запрос к http://<keycloak_url>/realms/<realm>/.well-known/openid-configuration, в ответе будет вся конфигурация, тебе надо взять адрес из token_endpoint - это адрес token service.

http://<keycloak_url>/realms/<realm>/.well-known/openid-configuration
token_endpoint

Спасибо.

А что такое token-service с адреса http://<keycloak_url>/realms/<realm>/?

Есть «token endpoint» - адрес, где получаем токен. Что подразумевается под «token service»?

Что подразумевается под «token service»?

По адресу http://<keycloak_url>/realms/<realm>/ выдаётся JSON, в котором есть элемент token-service, представляющий собой URL. Если его открыть, будет «Page not found».

Всё правильно, там страницы нет.

А зачем этот URL нужен?

Чтобы через POST-запрос по коду получить acess_token/refresh_token. GET запросов там нет, и никаких страниц тоже нет.

Какая разница между token_endpoint и token-service?

Это одно и то же.

У меня они разные, поэтому и спрашиваю. И если token_endpoint сразу сообщил, что GET — неподходящий тип запроса (405), а на мусорный POST сказал, что неверные данные, то token-service на всё отвечает 404.