From 3a4459bdd83744a3cd3a698997a6a4b483b0c6e0 Mon Sep 17 00:00:00 2001 From: Jonathan Huot Date: Fri, 18 Oct 2019 17:17:43 +0200 Subject: Initial custom grant type documentation. Improved Grant Type section to let developers create or implement their own custom grant type. Or also help them implementing new RFC. --- docs/oauth2/grants/custom_grant.rst | 49 ++++++++++++++++++++++++++++++++ docs/oauth2/grants/custom_validators.rst | 12 +++++++- docs/oauth2/grants/grants.rst | 28 +++++++++++------- docs/oauth2/grants/refresh.rst | 6 ++++ tox.ini | 2 +- 5 files changed, 85 insertions(+), 12 deletions(-) create mode 100644 docs/oauth2/grants/custom_grant.rst create mode 100644 docs/oauth2/grants/refresh.rst diff --git a/docs/oauth2/grants/custom_grant.rst b/docs/oauth2/grants/custom_grant.rst new file mode 100644 index 0000000..ba5446c --- /dev/null +++ b/docs/oauth2/grants/custom_grant.rst @@ -0,0 +1,49 @@ +Custom Grant type +----------------- + +Writing a custom grant type can be useful to implement a specification +which is in an early draft, or implement a grant provided by a +specific OAuth2.0 Authorization Server documentation but not provided +by oauthlib. For information, any grant types with a clear +specification can be integrated in oauthlib, just make a PR for that +!. See :doc:`how to contribute here `. + +Please find below an example of how to create a new grant and use it +in an endpoint: + +.. contents:: Tutorial Contents + :depth: 3 + + +1. Define your Grant Type +------------------------- + +The heart of your code is done by subclassing +:py:class:`oauthlib.oauth2.rfc6749.grant_types.base.GrantTypeBase`. +If you want to use it in the Authorize endpoint, you will have to +implement `create_authorization_response`, if in the Token endpoint, +implement `create_token_response`. + + +2. Associate it with Endpoints +------------------------------ +Then, once declared, you have to create an instance of your grant and +add it to your +endpoint. I.e. :py:class:`oauthlib.oauth2.rfc6749.endpoints.AuthorizationEndpoint` +or :py:class:`oauthlib.oauth2.rfc6749.endpoints.TokenEndpoint`. You +can see concrete examples in +:py:class:`oauthlib.oauth2.rfc6749.endpoints.pre_configured.Server` +for examples. + +3. Example +---------- + +To be completed. + +.. code-block:: python + class XXXZZZGrant(GrantTypeBase): + def create_token_response(self, request, token_handler): + if not request.grant_type == 'xxx_zzz': + raise errors.UnsupportedGrantTypeError(request=request) + ... + diff --git a/docs/oauth2/grants/custom_validators.rst b/docs/oauth2/grants/custom_validators.rst index 4629e6f..9917dd7 100644 --- a/docs/oauth2/grants/custom_validators.rst +++ b/docs/oauth2/grants/custom_validators.rst @@ -1,5 +1,15 @@ Custom Validators ----------------- -.. autoclass:: oauthlib.oauth2.rfc6749.grant_types.base.ValidatorsContainer +The Custom validators are useful when you want to change a particular +behavior of an existing grant. That is often needed because of the +diversity of the identity softwares and to let the oauthlib framework to be +flexible as possible. + +However, if you are looking into writing a custom grant type, please +refer to the :doc:`Custom Grant Type ` +instead. + +.. autoclass:: + oauthlib.oauth2.rfc6749.grant_types.base.ValidatorsContainer :members: diff --git a/docs/oauth2/grants/grants.rst b/docs/oauth2/grants/grants.rst index 16b17be..d2d9dcc 100644 --- a/docs/oauth2/grants/grants.rst +++ b/docs/oauth2/grants/grants.rst @@ -9,23 +9,30 @@ Grant types implicit password credentials - custom_validators + refresh jwt + custom_validators + custom_grant -Grant types are what make OAuth 2 so flexible. The Authorization Code grant is -very similar to OAuth 1 (with less crypto), the Implicit grant serves less -secure applications such as mobile applications, the Resource Owner Password -Credentials grant allows for legacy applications to incrementally transition to -OAuth 2, the Client Credentials grant is excellent for embedded services and -backend applications. +Grant types are what make OAuth 2 so flexible. The :doc:`Authorization +Code grant ` is the default for almost all +Web Applications, the :doc:`Implicit grant ` +serves less secure applications such as Mobile Applications or +Single-Page Applications, the :doc:`Client Credentials grant +` is excellent for embedded services and +backend applications. We have also the :doc:`Resource Owner Password +Credentials grant ` for legacy applications +to incrementally transition to OAuth 2. The main purpose of the grant types is to authorize access to protected resources in various ways with different security credentials. Naturally, OAuth 2 allows for extension grant types to be defined and OAuthLib -attempts to cater for easy inclusion of this as much as possible. +attempts to cater for easy inclusion of this as much as possible. See +:doc:`Custom Grant Type `. -OAuthlib also offers hooks for registering your own custom validations for use +OAuthlib also offers hooks for registering your own :doc:`Custom +Validators ` for use with the existing grant type handlers (:py:class:`oauthlib.oauth2.rfc6749.grant_types.base.ValidatorsContainer`). In some situations, this may be more convenient than subclassing or writing @@ -36,6 +43,7 @@ client to request new tokens for as long as you as provider allow them too. In general, OAuth 2 tokens should expire quickly and rather than annoying the user by require them to go through the authorization redirect loop you may use the refresh token to get a new access token. Refresh tokens, contrary to what their -name suggest, are components of a grant type rather than token types (like +name suggest, are components of a grant type (see :doc:`Refresh Token +grant `) rather than token types (like Bearer tokens), much like the authorization code in the authorization code grant. diff --git a/docs/oauth2/grants/refresh.rst b/docs/oauth2/grants/refresh.rst new file mode 100644 index 0000000..df925ff --- /dev/null +++ b/docs/oauth2/grants/refresh.rst @@ -0,0 +1,6 @@ +Refresh Token Grant +------------------------ + +.. autoclass:: oauthlib.oauth2.RefreshTokenGrant + :members: + :inherited-members: diff --git a/tox.ini b/tox.ini index 22f6f33..abb72ca 100644 --- a/tox.ini +++ b/tox.ini @@ -11,7 +11,7 @@ commands= # tox -e docs to mimick readthedocs build. # as of today, RTD is using python2.7 and doesn't run "setup.py install" [testenv:docs] -basepython=python2.7 +basepython=python3.6 skipsdist=True deps= sphinx -- cgit v1.2.1 From 842f5da2702ad76bb043c48ad5726da754277828 Mon Sep 17 00:00:00 2001 From: Jonathan Huot Date: Fri, 25 Oct 2019 11:10:27 +0200 Subject: Added clarity about ROPC & usage from RFC --- docs/oauth2/grants/grants.rst | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/docs/oauth2/grants/grants.rst b/docs/oauth2/grants/grants.rst index d2d9dcc..e183761 100644 --- a/docs/oauth2/grants/grants.rst +++ b/docs/oauth2/grants/grants.rst @@ -21,8 +21,10 @@ serves less secure applications such as Mobile Applications or Single-Page Applications, the :doc:`Client Credentials grant ` is excellent for embedded services and backend applications. We have also the :doc:`Resource Owner Password -Credentials grant ` for legacy applications -to incrementally transition to OAuth 2. +Credentials grant ` when there is a high +degree of trust between the resource owner and the client, and when +other authorization grant types are not available. This is also often +used for legacy applications to incrementally transition to OAuth 2. The main purpose of the grant types is to authorize access to protected resources in various ways with different security credentials. -- cgit v1.2.1 From f68ec220d9ff5ec8e710d3e916318dad0de3e2d2 Mon Sep 17 00:00:00 2001 From: Jonathan Huot Date: Fri, 25 Oct 2019 11:28:51 +0200 Subject: Add custom grant example --- docs/oauth2/grants/custom_grant.rst | 26 ++++++++++++++++++++------ 1 file changed, 20 insertions(+), 6 deletions(-) diff --git a/docs/oauth2/grants/custom_grant.rst b/docs/oauth2/grants/custom_grant.rst index ba5446c..7408cf6 100644 --- a/docs/oauth2/grants/custom_grant.rst +++ b/docs/oauth2/grants/custom_grant.rst @@ -1,5 +1,6 @@ +================= Custom Grant type ------------------ +================= Writing a custom grant type can be useful to implement a specification which is in an early draft, or implement a grant provided by a @@ -38,12 +39,25 @@ for examples. 3. Example ---------- -To be completed. +Sample below shows the creation of a new custom `grant_type` parameter +and declare it in the `/token` endpoint of your `Server`. Note that +you can reuse `pre_configured.Server` or use your own class inheriting +of the `Endpoint` classes you have decided. .. code-block:: python - class XXXZZZGrant(GrantTypeBase): + + class MyCustomGrant(GrantTypeBase): def create_token_response(self, request, token_handler): - if not request.grant_type == 'xxx_zzz': + if not request.grant_type == 'urn:ietf:params:oauth:grant-type:my-custom-grant': raise errors.UnsupportedGrantTypeError(request=request) - ... - + # implement your custom validation checks + # .. + + token = token_handler.create_token(request, + refresh_token=self.issue_new_refresh_tokens) + return self._get_default_headers(), json.dumps(token), 200 + + def setup_oauthlib(): + my_custom_grant = MyCustomGrant() + server = Server(request_validator) + server.grant_types["urn:ietf:params:oauth:grant-type:my-custom-grant"] = my_custom_grant -- cgit v1.2.1 From ab0de9e28db812eb204f12335b07d91361b16676 Mon Sep 17 00:00:00 2001 From: Jonathan Huot Date: Mon, 28 Oct 2019 16:10:22 +0100 Subject: Improved OIDC documentation --- docs/oauth2/oidc.rst | 17 +++++---- docs/oauth2/oidc/authcode.rst | 6 ++++ docs/oauth2/oidc/dispatchers.rst | 24 +++++++++++++ docs/oauth2/oidc/endpoints.rst | 21 +++++++++++ docs/oauth2/oidc/grants.rst | 41 ++++++++++++++++++++++ docs/oauth2/oidc/hybrid.rst | 6 ++++ docs/oauth2/oidc/implicit.rst | 6 ++++ docs/oauth2/oidc/userinfo.rst | 7 ++++ docs/oauth2/oidc/validator.rst | 33 ++++++++++++----- .../openid/connect/core/grant_types/dispatchers.py | 17 ++++++--- 10 files changed, 160 insertions(+), 18 deletions(-) create mode 100644 docs/oauth2/oidc/authcode.rst create mode 100644 docs/oauth2/oidc/dispatchers.rst create mode 100644 docs/oauth2/oidc/endpoints.rst create mode 100644 docs/oauth2/oidc/grants.rst create mode 100644 docs/oauth2/oidc/hybrid.rst create mode 100644 docs/oauth2/oidc/implicit.rst create mode 100644 docs/oauth2/oidc/userinfo.rst diff --git a/docs/oauth2/oidc.rst b/docs/oauth2/oidc.rst index d062386..a3810a6 100644 --- a/docs/oauth2/oidc.rst +++ b/docs/oauth2/oidc.rst @@ -1,16 +1,21 @@ OpenID Connect ============== -OpenID Connect represents a substantial set of behaviors and interactions built on the foundations of OAuth2. OAuthLib supports -OpenID Connect `Authentication flows`_ when the initial grant type request's ``scope`` parameter contains ``openid``. Clients wishing -to provide this support must implement several new features within their ``RequestValidator`` subclass. +OpenID Connect represents a substantial set of behaviors and +interactions built on the foundations of OAuth2. OAuthLib supports +OpenID Connect `Authentication flows`_ when the initial grant type +request's ``scope`` parameter contains ``openid``. Providers wishing +to provide this support must implement a couple of new features within +their ``RequestValidator`` subclass. + +A new userinfo endpoint can also be implemented to fulfill the core of OIDC. .. _`Authentication flows`: http://openid.net/specs/openid-connect-core-1_0.html#Authentication .. toctree:: :maxdepth: 2 - oidc/id_tokens oidc/validator - - + oidc/endpoints + oidc/grants + oidc/id_tokens diff --git a/docs/oauth2/oidc/authcode.rst b/docs/oauth2/oidc/authcode.rst new file mode 100644 index 0000000..11c4a62 --- /dev/null +++ b/docs/oauth2/oidc/authcode.rst @@ -0,0 +1,6 @@ +OpenID Authorization Code +------------------------- + +.. autoclass:: oauthlib.openid.connect.core.grant_types.AuthorizationCodeGrant + :members: + :inherited-members: diff --git a/docs/oauth2/oidc/dispatchers.rst b/docs/oauth2/oidc/dispatchers.rst new file mode 100644 index 0000000..f4d395e --- /dev/null +++ b/docs/oauth2/oidc/dispatchers.rst @@ -0,0 +1,24 @@ +Dispatchers +----------- + +.. contents:: + :depth: 2 + +Authorization Request +^^^^^^^^^^^^^^^^^^^^^ + +.. autoclass:: oauthlib.openid.connect.core.grant_types.ImplicitTokenGrantDispatcher + :members: + :inherited-members: + + +.. autoclass:: oauthlib.openid.connect.core.grant_types.AuthorizationCodeGrantDispatcher + :members: + :inherited-members: + +Token Request +^^^^^^^^^^^^^ + +.. autoclass:: oauthlib.openid.connect.core.grant_types.AuthorizationTokenGrantDispatcher + :members: + :inherited-members: diff --git a/docs/oauth2/oidc/endpoints.rst b/docs/oauth2/oidc/endpoints.rst new file mode 100644 index 0000000..51cd1e9 --- /dev/null +++ b/docs/oauth2/oidc/endpoints.rst @@ -0,0 +1,21 @@ +OpenID Provider Endpoints +========================= + +Endpoints in OpenID Connect Core adds a new UserInfo Endpoint. All +existing OAuth2.0 endpoints are common to both protocols. + +.. toctree:: + :maxdepth: 2 + + userinfo + +See also the related endpoints from OAuth2.0: + +.. hlist:: + :columns: 1 + + * :doc:`Authorization endpoint ` + * :doc:`Introspect endpoint ` + * :doc:`Token endpoint ` + * :doc:`Revocation endpoint ` + * :doc:`Resource endpoint ` diff --git a/docs/oauth2/oidc/grants.rst b/docs/oauth2/oidc/grants.rst new file mode 100644 index 0000000..aa1f70f --- /dev/null +++ b/docs/oauth2/oidc/grants.rst @@ -0,0 +1,41 @@ +=========== +Grant types +=========== + +The OpenID Connect specification adds a new `Hybrid` flow and adds +variants to the existing `Authorization Code` and `Implicit` +flows. They share the same principle: having `openid` in the scope and +a combination of new `response_type` values. + + +.. list-table:: OpenID Connect "response_type" Values + :widths: 50 50 + :header-rows: 1 + + * - "response_type" value + - Flow + * - `code` + - Authorization Code Flow + * - `id_token` + - Implicit Flow + * - `id_token token` + - Implicit Flow + * - `code id_token` + - Hybrid Flow + * - `code token` + - Hybrid Flow + * - `code id_token token` + - Hybrid Flow + + +Special Dispatcher classes have been made to dynamically route the HTTP +requests to either an OAuth2.0 flow or an OIDC flow. It basically +checks the presence of `openid` scope in the parameters. + +.. toctree:: + :maxdepth: 2 + + dispatchers + authcode + implicit + hybrid diff --git a/docs/oauth2/oidc/hybrid.rst b/docs/oauth2/oidc/hybrid.rst new file mode 100644 index 0000000..6a6c2e7 --- /dev/null +++ b/docs/oauth2/oidc/hybrid.rst @@ -0,0 +1,6 @@ +OpenID Hybrid +------------- + +.. autoclass:: oauthlib.openid.connect.core.grant_types.HybridGrant + :members: + :inherited-members: diff --git a/docs/oauth2/oidc/implicit.rst b/docs/oauth2/oidc/implicit.rst new file mode 100644 index 0000000..08cef20 --- /dev/null +++ b/docs/oauth2/oidc/implicit.rst @@ -0,0 +1,6 @@ +OpenID Implicit +--------------- + +.. autoclass:: oauthlib.openid.connect.core.grant_types.ImplicitGrant + :members: + :inherited-members: diff --git a/docs/oauth2/oidc/userinfo.rst b/docs/oauth2/oidc/userinfo.rst new file mode 100644 index 0000000..7ba4fbf --- /dev/null +++ b/docs/oauth2/oidc/userinfo.rst @@ -0,0 +1,7 @@ +======================== +OpenID UserInfo endpoint +======================== + + +.. autoclass:: oauthlib.openid.connect.core.endpoints.userinfo.UserInfoEndpoint + :members: diff --git a/docs/oauth2/oidc/validator.rst b/docs/oauth2/oidc/validator.rst index 17f5825..a04e12e 100644 --- a/docs/oauth2/oidc/validator.rst +++ b/docs/oauth2/oidc/validator.rst @@ -1,7 +1,16 @@ -OpenID Connect -========================================= +Creating a Provider +============================================= -Migrate your OAuth2.0 server into an OIDC provider +.. contents:: + :depth: 2 + +1. Create an OIDC provider +----------------------- +If you don't have an OAuth2.0 Provider, you can follow the instructions at +:doc:`OAuth2.0 Creating a Provider `. Then, follow the +migration step below. + +2. Migrate your OAuth2.0 provider into an OIDC provider ---------------------------------------------------- If you have a OAuth2.0 provider running and want to upgrade to OIDC, you can @@ -19,13 +28,21 @@ Into from oauthlib.openid import Server from oauthlib.openid import RequestValidator -Then, you have to implement the new RequestValidator methods as shown below. -Note that a new UserInfo endpoint is defined and need a new controller into your webserver. +Then, you have to implement the new `RequestValidator` methods as +shown below. Note also that a new :doc:`UserInfo endpoint ` can be defined +and needs a new controller into your webserver. -RequestValidator Extension ----------------------------------------------------- +3. Extend RequestValidator +-------------------------- -A couple of methods must be implemented in your validator subclass if you wish to support OpenID Connect: +A couple of methods must be implemented in your validator subclass if +you wish to support OpenID Connect: .. autoclass:: oauthlib.openid.RequestValidator :members: + +4. Preconfigured all-in-one servers +----------------------------------- + +.. autoclass:: oauthlib.openid.connect.core.endpoints.pre_configured.Server + :members: diff --git a/oauthlib/openid/connect/core/grant_types/dispatchers.py b/oauthlib/openid/connect/core/grant_types/dispatchers.py index 541467a..e6a9259 100644 --- a/oauthlib/openid/connect/core/grant_types/dispatchers.py +++ b/oauthlib/openid/connect/core/grant_types/dispatchers.py @@ -9,8 +9,10 @@ class Dispatcher: class AuthorizationCodeGrantDispatcher(Dispatcher): """ - This is an adapter class that will route simple Authorization Code requests, those that have response_type=code and a scope - including 'openid' to either the default_grant or the oidc_grant based on the scopes requested. + This is an adapter class that will route simple Authorization Code + requests, those that have `response_type=code` and a scope including + `openid` to either the `default_grant` or the `oidc_grant` based on + the scopes requested. """ def __init__(self, default_grant=None, oidc_grant=None): self.default_grant = default_grant @@ -26,16 +28,20 @@ class AuthorizationCodeGrantDispatcher(Dispatcher): return handler def create_authorization_response(self, request, token_handler): + """Read scope and route to the designated handler.""" return self._handler_for_request(request).create_authorization_response(request, token_handler) def validate_authorization_request(self, request): + """Read scope and route to the designated handler.""" return self._handler_for_request(request).validate_authorization_request(request) class ImplicitTokenGrantDispatcher(Dispatcher): """ - This is an adapter class that will route simple Authorization Code requests, those that have response_type=code and a scope - including 'openid' to either the default_grant or the oidc_grant based on the scopes requested. + This is an adapter class that will route simple Authorization + requests, those that have `id_token` in `response_type` and a scope + including `openid` to either the `default_grant` or the `oidc_grant` + based on the scopes requested. """ def __init__(self, default_grant=None, oidc_grant=None): self.default_grant = default_grant @@ -51,9 +57,11 @@ class ImplicitTokenGrantDispatcher(Dispatcher): return handler def create_authorization_response(self, request, token_handler): + """Read scope and route to the designated handler.""" return self._handler_for_request(request).create_authorization_response(request, token_handler) def validate_authorization_request(self, request): + """Read scope and route to the designated handler.""" return self._handler_for_request(request).validate_authorization_request(request) @@ -87,5 +95,6 @@ class AuthorizationTokenGrantDispatcher(Dispatcher): return handler def create_token_response(self, request, token_handler): + """Read scope and route to the designated handler.""" handler = self._handler_for_request(request) return handler.create_token_response(request, token_handler) -- cgit v1.2.1 From 1645cd3f0f3142384b76b402859474a6d0cd68e7 Mon Sep 17 00:00:00 2001 From: Jonathan Huot Date: Mon, 28 Oct 2019 18:09:27 +0100 Subject: Improve clarity around howto define a grant. --- docs/oauth2/grants/custom_grant.rst | 67 +++++++++++++++++++++++-------------- 1 file changed, 41 insertions(+), 26 deletions(-) diff --git a/docs/oauth2/grants/custom_grant.rst b/docs/oauth2/grants/custom_grant.rst index 7408cf6..b47131c 100644 --- a/docs/oauth2/grants/custom_grant.rst +++ b/docs/oauth2/grants/custom_grant.rst @@ -7,10 +7,9 @@ which is in an early draft, or implement a grant provided by a specific OAuth2.0 Authorization Server documentation but not provided by oauthlib. For information, any grant types with a clear specification can be integrated in oauthlib, just make a PR for that -!. See :doc:`how to contribute here `. +! See :doc:`how to contribute here `. -Please find below an example of how to create a new grant and use it -in an endpoint: +Please find how to create a new grant and use it in an endpoint: .. contents:: Tutorial Contents :depth: 3 @@ -18,46 +17,62 @@ in an endpoint: 1. Define your Grant Type ------------------------- - The heart of your code is done by subclassing -:py:class:`oauthlib.oauth2.rfc6749.grant_types.base.GrantTypeBase`. -If you want to use it in the Authorize endpoint, you will have to -implement `create_authorization_response`, if in the Token endpoint, -implement `create_token_response`. +:py:class:`GrantTypeBase`. If you want to use it in the Authorize +endpoint, you will have to implement +:py:meth:`create_authorization_response`, if you want to use the Token +endpoint, implement :py:meth:`create_token_response`. You can also +implement both. + +2. Implement the grant +---------------------- +Inside the method's implementation, you will have to: +* add validations of the request (syntax, parameters, ...) +* call and orchestrate one or multiple Request Validators calls +* generate and return HTTP response -2. Associate it with Endpoints +You can define new Request Validator methods if needed, or reuse the +existing ones. + +3. Associate it with Endpoints ------------------------------ -Then, once declared, you have to create an instance of your grant and -add it to your -endpoint. I.e. :py:class:`oauthlib.oauth2.rfc6749.endpoints.AuthorizationEndpoint` -or :py:class:`oauthlib.oauth2.rfc6749.endpoints.TokenEndpoint`. You -can see concrete examples in -:py:class:`oauthlib.oauth2.rfc6749.endpoints.pre_configured.Server` -for examples. - -3. Example +Then, once implemented, you have to instanciate the grant object and +bind it to your endpoint. Either :py:class:`AuthorizationEndpoint`, +:py:class:`TokenEndpoint` or both. + +4. Example ---------- +This example shows how to add a simple extension to the `Token endpoint`: -Sample below shows the creation of a new custom `grant_type` parameter -and declare it in the `/token` endpoint of your `Server`. Note that -you can reuse `pre_configured.Server` or use your own class inheriting -of the `Endpoint` classes you have decided. +* creation of a new class ``MyCustomGrant``, and implement ``create_token_response``. +* do basics and custom request validations, then call a custom method + of `Request Validator` to extend the interface for the implementor. +* instanciate the new grant, and bind it with an existing ``Server``. .. code-block:: python + grant_name = 'urn:ietf:params:oauth:grant-type:my-custom-grant' + class MyCustomGrant(GrantTypeBase): def create_token_response(self, request, token_handler): - if not request.grant_type == 'urn:ietf:params:oauth:grant-type:my-custom-grant': + if not request.grant_type == grant_name: raise errors.UnsupportedGrantTypeError(request=request) + # implement your custom validation checks # .. + self.request_validator.your_custom_check(request) - token = token_handler.create_token(request, - refresh_token=self.issue_new_refresh_tokens) + token = token_handler.create_token(request) return self._get_default_headers(), json.dumps(token), 200 def setup_oauthlib(): my_custom_grant = MyCustomGrant() server = Server(request_validator) - server.grant_types["urn:ietf:params:oauth:grant-type:my-custom-grant"] = my_custom_grant + server.grant_types[grant_name] = my_custom_grant + + +You can find concrete examples directly in the code source of existing +grants and existing servers. See Grant Types in +:py:mod:`oauthlib.oauth2.rfc749.grant_types`, and Servers in +:py:mod:`oauthlib.oauth2.rfc749.endpoints.pre_configured` -- cgit v1.2.1 From 00d4d5a62d4bf18fd2642cd667f7e2002211668c Mon Sep 17 00:00:00 2001 From: Dan Piet Date: Mon, 13 Jan 2020 13:20:05 -0500 Subject: update server.rst docs necessary auth code fields --- docs/oauth2/server.rst | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/docs/oauth2/server.rst b/docs/oauth2/server.rst index d9846c5..15420f3 100644 --- a/docs/oauth2/server.rst +++ b/docs/oauth2/server.rst @@ -239,6 +239,17 @@ the token. # the scopes into a string. scopes = django.db.models.TextField() +**Redirect URI**: + + If the client specifies a redirect_uri when obtaining code then that + redirect URI must be bound to the code and verified equal in this + method, according to RFC 6749 section 4.1. This field holds that + bound value. + + .. code-block:: python + + redirect_uri = django.db.models.TextField() + **Authorization Code**: An unguessable unique string of characters. -- cgit v1.2.1 From 6e4fb41ffb04024d5301cadad662e6bbb4893901 Mon Sep 17 00:00:00 2001 From: Jonathan Huot Date: Wed, 15 Jan 2020 10:48:03 +0100 Subject: Removed newline/autoformatting mistake fixed --- docs/oauth2/grants/custom_grant.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/oauth2/grants/custom_grant.rst b/docs/oauth2/grants/custom_grant.rst index b47131c..8c4571c 100644 --- a/docs/oauth2/grants/custom_grant.rst +++ b/docs/oauth2/grants/custom_grant.rst @@ -6,8 +6,8 @@ Writing a custom grant type can be useful to implement a specification which is in an early draft, or implement a grant provided by a specific OAuth2.0 Authorization Server documentation but not provided by oauthlib. For information, any grant types with a clear -specification can be integrated in oauthlib, just make a PR for that -! See :doc:`how to contribute here `. +specification can be integrated in oauthlib, just make a PR for that ! +See :doc:`how to contribute here `. Please find how to create a new grant and use it in an endpoint: -- cgit v1.2.1