OID C, OAuth2.0 и роль маркера доступа, когда клиентское приложение OAuth и сервер ресурсов не различаются

Question

Я работаю над веб-приложением ASP.NET MVC 5. Он имеет только один слой, который содержит представления, а также бизнес-логику / операции. Бизнес-логика c логически отделена от пользовательского интерфейса, но не находится за отдельным слоем веб-службы / API.

Теперь, когда я использую OIDC и OAuth2.0 для своего приложения, отдельного * 1006 нет *, так сказать. Поскольку сам Клиент имеет все ресурсы, к которым я хочу иметь доступ.

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

Вопросы:

1. Имеет access token иметь какую-либо роль в этом случае? Если да, то что?
2. Как я собираюсь практически использовать токен доступа? Поскольку сам клиент является сервером ресурсов, мне не нужно отправлять токен доступа.

Answer 1

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

Когда у вас есть информация о пользователе, вы можете реализовать ее между браузером и вашим ASP. NET бэкэндом в тем не мение. Вы можете взглянуть на OAuth 2.0 для приложений на основе браузера RF C.

Answer 2

В этом случае вы должны использовать поток учетных данных клиента вместо потока кода авторизации. В потоке учетных данных клиента ваше приложение будет отправлять ваш идентификатор клиента и секрет клиента в конечную точку авторизации напрямую и запрашивать токен доступа. Код авторизации не требуется в потоке учетных данных клиента. Подробности приведены ниже

1. Поток кода авторизации обычно требует, чтобы ваш клиент перенаправил владельца ресурса на конечную точку авторизации и получил код авторизации от конечной точки авторизации, клиента, чем использует этот код для получения токена доступа, в конце Дневной клиент использует токен доступа для доступа к защищенному ресурсу.
2. В клиентском потоке. Ваше клиентское приложение фактически является владельцем вашего ресурса. Поэтому нет необходимости запрашивать код авторизации. direct использует собственные учетные данные клиента для получения токена доступа от конечной точки авторизации и использования этого токена доступа для доступа к защищенному ресурсу (серверу ресурсов)