Skip to content

Commit af5ac6d

Browse files
authored
Merge branch 'master' into doc-sponsor
2 parents 75b9f4f + 82544c2 commit af5ac6d

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

61 files changed

+389
-95
lines changed

CHANGELOG.rst

+34-16
Original file line numberDiff line numberDiff line change
@@ -1,33 +1,51 @@
11
Changelog
22
=========
33

4-
3.1.0 (TBD)
4+
3.1.1 (TBD)
55
------------------
6+
OAuth2.0 Client - Bugfixes
67

8+
* #730: Base OAuth2 Client now has a consistent way of managing the `scope`: it consistently
9+
relies on the `scope` provided in the constructor if any, except if overridden temporarily
10+
in a method call. Note that in particular providing a non-None `scope` in
11+
`prepare_authorization_request` or `prepare_refresh_token` does not override anymore
12+
`self.scope` forever, it is just used temporarily.
13+
* #726: MobileApplicationClient.prepare_request_uri and MobileApplicationClient.parse_request_uri_response,
14+
ServiceApplicationClient.prepare_request_body,
15+
and WebApplicationClient.prepare_request_uri now correctly use the default `scope` provided in
16+
constructor.
17+
* #725: LegacyApplicationClient.prepare_request_body now correctly uses the default `scope` provided in constructor
18+
19+
3.1.0 (2019-08-06)
20+
------------------
721
OAuth2.0 Provider - Features
8-
* #660: OIDC add support of nonce, c_hash, at_hash fields
9-
- New RequestValidator.fill_id_token method
10-
- Deprecated RequestValidator.get_id_token method
11-
* #677: OIDC add UserInfo endpoint
12-
- New RequestValidator.get_userinfo_claims method
22+
23+
* #660: OIDC add support of `nonce`, `c_hash`, `at_hash fields`
24+
- New `RequestValidator.fill_id_token` method
25+
- Deprecated `RequestValidator.get_id_token` method
26+
* #677: OIDC add `UserInfo` endpoint - New `RequestValidator.get_userinfo_claims` method
1327

1428
OAuth2.0 Provider - Security
15-
* #665: Enhance data leak to logs
16-
- New default to not expose request content in logs
17-
- New function `oauthlib.set_debug(True)`
18-
* #666: Disabling query parameters for POST requests
29+
30+
* #665: Enhance data leak to logs
31+
* New default to not expose request content in logs
32+
* New function `oauthlib.set_debug(True)`
33+
* #666: Disabling query parameters for POST requests
1934

2035
OAuth2.0 Provider - Bugfixes
21-
* #670: Fix validate_authorization_request to return the new PKCE fields
22-
* #674: Fix token_type to be case-insensitive (bearer and Bearer)
36+
37+
* #670: Fix `validate_authorization_request` to return the new PKCE fields
38+
* #674: Fix `token_type` to be case-insensitive (`bearer` and `Bearer`)
2339

2440
OAuth2.0 Client - Bugfixes
25-
* #290: Fix Authorization Code's errors processing
26-
* #603: BackendApplication.Client.prepare_request_body use the "scope" argument as intended.
27-
* #672: Fix edge case when expires_in=Null
41+
42+
* #290: Fix Authorization Code's errors processing
43+
* #603: BackendApplicationClient.prepare_request_body use the `scope` argument as intended.
44+
* #672: Fix edge case when `expires_in=Null`
2845

2946
OAuth1.0 Client
30-
* #669: Add case-insensitive headers to oauth1 BaseEndpoint
47+
48+
* #669: Add case-insensitive headers to oauth1 `BaseEndpoint`
3149

3250
3.0.2 (2019-07-04)
3351
------------------

docs/oauth2/grants/custom_grant.rst

+78
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,78 @@
1+
=================
2+
Custom Grant type
3+
=================
4+
5+
Writing a custom grant type can be useful to implement a specification
6+
which is in an early draft, or implement a grant provided by a
7+
specific OAuth2.0 Authorization Server documentation but not provided
8+
by oauthlib. For information, any grant types with a clear
9+
specification can be integrated in oauthlib, just make a PR for that !
10+
See :doc:`how to contribute here </contributing>`.
11+
12+
Please find how to create a new grant and use it in an endpoint:
13+
14+
.. contents:: Tutorial Contents
15+
:depth: 3
16+
17+
18+
1. Define your Grant Type
19+
-------------------------
20+
The heart of your code is done by subclassing
21+
:py:class:`GrantTypeBase`. If you want to use it in the Authorize
22+
endpoint, you will have to implement
23+
:py:meth:`create_authorization_response`, if you want to use the Token
24+
endpoint, implement :py:meth:`create_token_response`. You can also
25+
implement both.
26+
27+
2. Implement the grant
28+
----------------------
29+
Inside the method's implementation, you will have to:
30+
31+
* add validations of the request (syntax, parameters, ...)
32+
* call and orchestrate one or multiple Request Validators calls
33+
* generate and return HTTP response
34+
35+
You can define new Request Validator methods if needed, or reuse the
36+
existing ones.
37+
38+
3. Associate it with Endpoints
39+
------------------------------
40+
Then, once implemented, you have to instanciate the grant object and
41+
bind it to your endpoint. Either :py:class:`AuthorizationEndpoint`,
42+
:py:class:`TokenEndpoint` or both.
43+
44+
4. Example
45+
----------
46+
This example shows how to add a simple extension to the `Token endpoint`:
47+
48+
* creation of a new class ``MyCustomGrant``, and implement ``create_token_response``.
49+
* do basics and custom request validations, then call a custom method
50+
of `Request Validator` to extend the interface for the implementor.
51+
* instanciate the new grant, and bind it with an existing ``Server``.
52+
53+
.. code-block:: python
54+
55+
grant_name = 'urn:ietf:params:oauth:grant-type:my-custom-grant'
56+
57+
class MyCustomGrant(GrantTypeBase):
58+
def create_token_response(self, request, token_handler):
59+
if not request.grant_type == grant_name:
60+
raise errors.UnsupportedGrantTypeError(request=request)
61+
62+
# implement your custom validation checks
63+
# ..
64+
self.request_validator.your_custom_check(request)
65+
66+
token = token_handler.create_token(request)
67+
return self._get_default_headers(), json.dumps(token), 200
68+
69+
def setup_oauthlib():
70+
my_custom_grant = MyCustomGrant()
71+
server = Server(request_validator)
72+
server.grant_types[grant_name] = my_custom_grant
73+
74+
75+
You can find concrete examples directly in the code source of existing
76+
grants and existing servers. See Grant Types in
77+
:py:mod:`oauthlib.oauth2.rfc749.grant_types`, and Servers in
78+
:py:mod:`oauthlib.oauth2.rfc749.endpoints.pre_configured`
+11-1
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,15 @@
11
Custom Validators
22
-----------------
33

4-
.. autoclass:: oauthlib.oauth2.rfc6749.grant_types.base.ValidatorsContainer
4+
The Custom validators are useful when you want to change a particular
5+
behavior of an existing grant. That is often needed because of the
6+
diversity of the identity softwares and to let the oauthlib framework to be
7+
flexible as possible.
8+
9+
However, if you are looking into writing a custom grant type, please
10+
refer to the :doc:`Custom Grant Type </oauth2/grants/custom_grant>`
11+
instead.
12+
13+
.. autoclass::
14+
oauthlib.oauth2.rfc6749.grant_types.base.ValidatorsContainer
515
:members:

docs/oauth2/grants/grants.rst

+20-10
Original file line numberDiff line numberDiff line change
@@ -9,23 +9,32 @@ Grant types
99
implicit
1010
password
1111
credentials
12-
custom_validators
12+
refresh
1313
jwt
14+
custom_validators
15+
custom_grant
1416

15-
Grant types are what make OAuth 2 so flexible. The Authorization Code grant is
16-
very similar to OAuth 1 (with less crypto), the Implicit grant serves less
17-
secure applications such as mobile applications, the Resource Owner Password
18-
Credentials grant allows for legacy applications to incrementally transition to
19-
OAuth 2, the Client Credentials grant is excellent for embedded services and
20-
backend applications.
17+
Grant types are what make OAuth 2 so flexible. The :doc:`Authorization
18+
Code grant </oauth2/grants/authcode>` is the default for almost all
19+
Web Applications, the :doc:`Implicit grant </oauth2/grants/implicit>`
20+
serves less secure applications such as Mobile Applications or
21+
Single-Page Applications, the :doc:`Client Credentials grant
22+
</oauth2/grants/credentials>` is excellent for embedded services and
23+
backend applications. We have also the :doc:`Resource Owner Password
24+
Credentials grant </oauth2/grants/password>` when there is a high
25+
degree of trust between the resource owner and the client, and when
26+
other authorization grant types are not available. This is also often
27+
used for legacy applications to incrementally transition to OAuth 2.
2128

2229
The main purpose of the grant types is to authorize access to protected
2330
resources in various ways with different security credentials.
2431

2532
Naturally, OAuth 2 allows for extension grant types to be defined and OAuthLib
26-
attempts to cater for easy inclusion of this as much as possible.
33+
attempts to cater for easy inclusion of this as much as possible. See
34+
:doc:`Custom Grant Type </oauth2/grants/custom_grant>`.
2735

28-
OAuthlib also offers hooks for registering your own custom validations for use
36+
OAuthlib also offers hooks for registering your own :doc:`Custom
37+
Validators </oauth2/grants/custom_validators>` for use
2938
with the existing grant type handlers
3039
(:py:class:`oauthlib.oauth2.rfc6749.grant_types.base.ValidatorsContainer`).
3140
In some situations, this may be more convenient than subclassing or writing
@@ -36,6 +45,7 @@ client to request new tokens for as long as you as provider allow them too. In
3645
general, OAuth 2 tokens should expire quickly and rather than annoying the user
3746
by require them to go through the authorization redirect loop you may use the
3847
refresh token to get a new access token. Refresh tokens, contrary to what their
39-
name suggest, are components of a grant type rather than token types (like
48+
name suggest, are components of a grant type (see :doc:`Refresh Token
49+
grant </oauth2/grants/refresh>`) rather than token types (like
4050
Bearer tokens), much like the authorization code in the authorization code
4151
grant.

docs/oauth2/grants/refresh.rst

+6
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,6 @@
1+
Refresh Token Grant
2+
------------------------
3+
4+
.. autoclass:: oauthlib.oauth2.RefreshTokenGrant
5+
:members:
6+
:inherited-members:

docs/oauth2/oidc.rst

+11-6
Original file line numberDiff line numberDiff line change
@@ -1,16 +1,21 @@
11
OpenID Connect
22
==============
33

4-
OpenID Connect represents a substantial set of behaviors and interactions built on the foundations of OAuth2. OAuthLib supports
5-
OpenID Connect `Authentication flows`_ when the initial grant type request's ``scope`` parameter contains ``openid``. Clients wishing
6-
to provide this support must implement several new features within their ``RequestValidator`` subclass.
4+
OpenID Connect represents a substantial set of behaviors and
5+
interactions built on the foundations of OAuth2. OAuthLib supports
6+
OpenID Connect `Authentication flows`_ when the initial grant type
7+
request's ``scope`` parameter contains ``openid``. Providers wishing
8+
to provide this support must implement a couple of new features within
9+
their ``RequestValidator`` subclass.
10+
11+
A new userinfo endpoint can also be implemented to fulfill the core of OIDC.
712

813
.. _`Authentication flows`: http://openid.net/specs/openid-connect-core-1_0.html#Authentication
914

1015
.. toctree::
1116
:maxdepth: 2
1217

13-
oidc/id_tokens
1418
oidc/validator
15-
16-
19+
oidc/endpoints
20+
oidc/grants
21+
oidc/id_tokens

docs/oauth2/oidc/authcode.rst

+6
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,6 @@
1+
OpenID Authorization Code
2+
-------------------------
3+
4+
.. autoclass:: oauthlib.openid.connect.core.grant_types.AuthorizationCodeGrant
5+
:members:
6+
:inherited-members:

docs/oauth2/oidc/dispatchers.rst

+24
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,24 @@
1+
Dispatchers
2+
-----------
3+
4+
.. contents::
5+
:depth: 2
6+
7+
Authorization Request
8+
^^^^^^^^^^^^^^^^^^^^^
9+
10+
.. autoclass:: oauthlib.openid.connect.core.grant_types.ImplicitTokenGrantDispatcher
11+
:members:
12+
:inherited-members:
13+
14+
15+
.. autoclass:: oauthlib.openid.connect.core.grant_types.AuthorizationCodeGrantDispatcher
16+
:members:
17+
:inherited-members:
18+
19+
Token Request
20+
^^^^^^^^^^^^^
21+
22+
.. autoclass:: oauthlib.openid.connect.core.grant_types.AuthorizationTokenGrantDispatcher
23+
:members:
24+
:inherited-members:

docs/oauth2/oidc/endpoints.rst

+21
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,21 @@
1+
OpenID Provider Endpoints
2+
=========================
3+
4+
Endpoints in OpenID Connect Core adds a new UserInfo Endpoint. All
5+
existing OAuth2.0 endpoints are common to both protocols.
6+
7+
.. toctree::
8+
:maxdepth: 2
9+
10+
userinfo
11+
12+
See also the related endpoints from OAuth2.0:
13+
14+
.. hlist::
15+
:columns: 1
16+
17+
* :doc:`Authorization endpoint </oauth2/endpoints/authorization>`
18+
* :doc:`Introspect endpoint </oauth2/endpoints/introspect>`
19+
* :doc:`Token endpoint </oauth2/endpoints/token>`
20+
* :doc:`Revocation endpoint </oauth2/endpoints/revocation>`
21+
* :doc:`Resource endpoint </oauth2/endpoints/resource>`

docs/oauth2/oidc/grants.rst

+41
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,41 @@
1+
===========
2+
Grant types
3+
===========
4+
5+
The OpenID Connect specification adds a new `Hybrid` flow and adds
6+
variants to the existing `Authorization Code` and `Implicit`
7+
flows. They share the same principle: having `openid` in the scope and
8+
a combination of new `response_type` values.
9+
10+
11+
.. list-table:: OpenID Connect "response_type" Values
12+
:widths: 50 50
13+
:header-rows: 1
14+
15+
* - "response_type" value
16+
- Flow
17+
* - `code`
18+
- Authorization Code Flow
19+
* - `id_token`
20+
- Implicit Flow
21+
* - `id_token token`
22+
- Implicit Flow
23+
* - `code id_token`
24+
- Hybrid Flow
25+
* - `code token`
26+
- Hybrid Flow
27+
* - `code id_token token`
28+
- Hybrid Flow
29+
30+
31+
Special Dispatcher classes have been made to dynamically route the HTTP
32+
requests to either an OAuth2.0 flow or an OIDC flow. It basically
33+
checks the presence of `openid` scope in the parameters.
34+
35+
.. toctree::
36+
:maxdepth: 2
37+
38+
dispatchers
39+
authcode
40+
implicit
41+
hybrid

docs/oauth2/oidc/hybrid.rst

+6
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,6 @@
1+
OpenID Hybrid
2+
-------------
3+
4+
.. autoclass:: oauthlib.openid.connect.core.grant_types.HybridGrant
5+
:members:
6+
:inherited-members:

docs/oauth2/oidc/implicit.rst

+6
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,6 @@
1+
OpenID Implicit
2+
---------------
3+
4+
.. autoclass:: oauthlib.openid.connect.core.grant_types.ImplicitGrant
5+
:members:
6+
:inherited-members:

docs/oauth2/oidc/userinfo.rst

+7
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,7 @@
1+
========================
2+
OpenID UserInfo endpoint
3+
========================
4+
5+
6+
.. autoclass:: oauthlib.openid.connect.core.endpoints.userinfo.UserInfoEndpoint
7+
:members:

0 commit comments

Comments
 (0)