Может ли конечная точка токена Azure AD OAuth 2 принимать токен kerberos в качестве кода аутентификации?

#azure #oauth #kerberos #azure-active-directory

#azure #oauth #kerberos #azure-active-directory

Вопрос:

При выполнении потока OAuth 2.0 с Azure AD документированный процесс заключается в перенаправлении конечной точки аутентификации Oauth для получения authtoken, возвращает перенаправление при входе пользователя в систему, а затем вызывает конечную точку токена, чтобы получить ваш токен доступа, передающий код аутентификации. был дан первый шаг.

Приложения, для которых я это делаю, уже будут иметь токен kerberos, возможно ли получить токен доступа без перенаправления с помощью Azure AD? Например, может ли конечная точка OAuth принимать билет kerberos?

Основываясь на всем, что я прочитал, это нет. Я просто хотел проверить, так как было бы неплохо не выполнять перенаправление для улучшения пользовательского интерфейса.

Комментарии:

1. Что, если конечная цель получения токена доступа? К какому ресурсу (например, Azure AD Graph API и т. Д.?) Вы хотели бы получить токен доступа?

2. Аутентификация и авторизация. Получить JWT для использования в запросах API. Я просто пытался избежать перенаправления, что немного улучшает пользовательский интерфейс.

Ответ №1:

Тони,

Я предполагаю, что вы обращаетесь к потоку AuthorizationCodeFlow http://openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth . Короткий ответ — НЕТ. AAD выдает «код» и отслеживает артефакты запроса, чтобы он мог выдавать идентификаторы id_tokens и access_tokens, связанные с пользователем.

Ответ №2:

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

На данный момент единственными стандартными вариантами являются:

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