мы можем использовать идентификационный токен в качестве токена доступа? - PullRequest
Новая
       89

мы можем использовать идентификационный токен в качестве токена доступа?

0 голосов
/ 15 января 2020

Как я знаю, идентификатор токена выглядит следующим образом: 

{
  "iss": "http://YOUR_DOMAIN/",
  "sub": "authentication",
  "aud": "clien id",
  "exp": 1512285980,
  "iat": 1512280980,
  "name": "omid",
  "given_name": "omid",
  "family_name": "haghighatgoo",
  "gender": "male",
  "birthdate": "1987-10-31",
  "email": "a@b.com",

}

, а токен доступа выглядит так: 

{
  "iss": "https://YOUR_DOMAIN/",
  "sub": "authentication",
  "aud": [
    "api-identifier",
    "https://YOUR_DOMAIN/userinfo"
  ],
  "azp": "clientid",
  "exp": 1512285980,
  "iat": 1512280980,
  "scope": "profile email"
}

, поскольку очевидно, что все параметры в маркере доступа могут быть в идентификаторе тоже. так почему бы нам не использовать токен id в качестве токена доступа? Я имею в виду, что оба они могут обрабатываться одним токеном, если используется JWT.

1 Ответ

1 голос
/ 16 января 2020

OpenID connect строится поверх OAuth2 и добавляет маркер ID в качестве дополнительной функции. Ни в OpenID, ни в OAuth2 не указано, каким должен быть формат токена доступа (это не обязательно должен быть JWT), поэтому вы должны объяснить в своем вопросе, почему вы говорите, что он имеет этот формат (то есть, какой провайдер OpenID (OP) вы с помощью). Токен доступа также может быть непрозрачной ссылкой для предоставления данных, которые хранятся на OP (что также позволяет, например, аннулировать доступ).

Чтобы предоставить самый простой ответ, вы, вероятно, не можете Сделайте это просто потому, что ваш OP отклонит запрос, если вы это сделаете. Аудитория для токена ID - это клиент, а аудитория для токена доступа - OP. Они служат различным целям и будут кодироваться и проверяться по-разному.

Идентификационный токен - это информация для клиентского приложения, которая сообщает ему, кто является аутентифицированным пользователем. Скорее всего, он будет подписан с помощью алгоритма асимметрии c, чтобы клиент мог проверить его, выданный OP.

Клиентскому приложению вообще не нужно знать содержимое токена доступа или проверять Это. Маркер должен быть понят и проверен OP только тогда, когда он получает запрос в конечной точке userinfo.

...