Что определяет используемый тип гранта oauth2? - PullRequest
0 голосов
/ 11 апреля 2019

Как конечная точка oauth2 определяет тип предоставления запроса?

Является ли она самой конечной точкой (т.е. каждая конечная точка выделена одному или нескольким типам предоставления).Или это список параметров, отправленных в запросе?Или это значение параметра grant_type?

Например, anilist.co.

В документации oauth2 говорится, что для предоставления кода авторизации необходимо использовать следующую конечную точку с этими параметрами:

https://anilist.co/api/v2/oauth/authorize?client_id={client_id}&redirect_uri={redirect_uri}&response_type=code

Для неявного предоставления, он говорит использовать это:

https://anilist.co/api/v2/oauth/authorize?client_id={client_id}&response_type=token

(см: https://anilist.gitbook.io/anilist-apiv2-docs/overview/oauth/authorization-code-grant и https://anilist.gitbook.io/anilist-apiv2-docs/overview/oauth/implicit-grant)

Так что, похоже, у них есть одна конечная точка, которая определяет тип предоставления на основе значения response_type и наличия / отсутствия redirect_uri (другими словами, тип предоставления основан на параметрах).

Но так ли это всегда для каждого провайдера oauth2?

Согласно этому сайту здесь:

https://alexbilbie.com/guide-to-oauth-2-grants/

… код авторизации и неявные типы предоставления имеютточно такой же набор параметров, но различается на основе значения response_type (токен для неявного, код для кода авторизации). Но другие типы предоставления отличаются по значению grant_type. Почему не каждый тип предоставленияОтличается ли он значением гранта_типа?

Если бы я догадался, следовательно, я бы сказал, что тип гранта определяется значением grant_type, а там, где grant_type отсутствует, он определяется значением response_type.

Это правильно?Это стандарт в отрасли?

Ответы [ 2 ]

1 голос
/ 12 апреля 2019

определяется спецификацией RFC [rfc6749] [https://tools.ietf.org/html/rfc6749] 1

Этот RFC определяет все конечные точки, необходимые для реализации OAuth 2.0. Это до поставщика на реализацию. Но они должны будут придерживаться спецификации для совместимости. В противном случае собственные потоки могут не масштабироваться.

Фактически, вы также можете проверить спецификацию OpenIDConnect для получения более подробной информации. (https://openid.net/specs/openid-connect-core-1_0.html)

0 голосов
/ 12 апреля 2019

Просто добавим, что если вы хотите использовать OAuth 2.0 с собственным приложением, для этого есть другой RFC, т.е. https://tools.ietf.org/html/rfc8252

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...