|
| 1 | +--- |
| 2 | +outline: deep |
| 3 | +--- |
| 4 | + |
| 5 | +# Tutorials |
| 6 | + |
| 7 | +This documentation section covers samples and tutorials on important topics of using the library. Look at |
| 8 | +the [examples](https://github.com/pysnippet/fastapi-oauth2/tree/master/examples) |
| 9 | +and [tests](https://github.com/pysnippet/fastapi-oauth2/tree/master/tests) directories of the repository for other |
| 10 | +use-case implementations. Feel free to open an [issue](https://github.com/pysnippet/fastapi-oauth2/issues/new/choose) or |
| 11 | +a [discussion](https://github.com/pysnippet/fastapi-oauth2/discussions/new/choose) if your question is not covered by |
| 12 | +the documentation. |
| 13 | + |
| 14 | +## Authentication |
| 15 | + |
| 16 | +By following the [integration](/integration/integration) docs, for the basic user authentication, you must already have |
| 17 | +generated the client ID and secret to configure your `OAuth2Middleware` with at least one client configuration. |
| 18 | + |
| 19 | +1. Go to the developer console or settings of your OAuth2 identity provider and generate new client credentials. |
| 20 | +2. Provide the [client configuration](/integration/configuration#oauth2client) with the obtained client ID and secret |
| 21 | + into the clients of the middleware's config. |
| 22 | +3. Set the `redirect_uri` of your application that you have also configured in the IDP. |
| 23 | +4. Add the middleware and include the router to your application as shown in the [integration](/integration/integration) |
| 24 | + section. |
| 25 | +5. Open the `/oauth2/{provider}/auth` endpoint on your browser and test the authentication flow. Check out |
| 26 | + the [router](/integration/integration#router) for the `{provider}` variable. |
| 27 | + |
| 28 | +Once the authentication is successful, the user will be redirected to the `redirect_uri` and the `request.user` will |
| 29 | +contain the user information obtained from the IDP. |
| 30 | + |
| 31 | +## Access token |
| 32 | + |
| 33 | +When the user is authenticated, the `request.user` will contain the user information obtained from the IDP and |
| 34 | +the `request.auth` will contain the authentication related information including the access token issued by the IDP. It |
| 35 | +can be used to perform authorized requests to the IDP's API endpoints. Just make sure the token is issued with the |
| 36 | +scopes required for the API endpoint. |
| 37 | + |
| 38 | +::: details `request.auth.provider.access_token` |
| 39 | + |
| 40 | +```mermaid |
| 41 | +flowchart TB |
| 42 | + subgraph level2["request (Starlette's Request object)"] |
| 43 | + direction TB |
| 44 | + subgraph level1["auth (Starlette's extended Auth Credentials)"] |
| 45 | + direction TB |
| 46 | + subgraph level0["provider (OAuth2 provider with client's credentials)"] |
| 47 | + direction TB |
| 48 | + token["access_token (Access token for the specified scopes)"] |
| 49 | + end |
| 50 | + end |
| 51 | + end |
| 52 | + style level2 fill:#00948680,color:#f6f6f7,stroke:#3c3c43; |
| 53 | + style level1 fill:#2b75a080,color:#f6f6f7,stroke:#3c3c43; |
| 54 | + style level0 fill:#5c837480,color:#f6f6f7,stroke:#3c3c43; |
| 55 | + style token fill:#44506980,color:#f6f6f7,stroke:#3c3c43; |
| 56 | +``` |
| 57 | + |
| 58 | +::: |
| 59 | + |
| 60 | +## Claims mapping |
| 61 | + |
| 62 | +The `Claims` class includes permanent attributes like `display_name`, `identity`, `picture`, and `email`. It also allows |
| 63 | +for custom attributes. Each attribute can either be a string or a callable function that takes user data and returns a |
| 64 | +string. Suppose the user data obtained from IDP looks like follows, and you need to map the corresponding attributes for |
| 65 | +the user provisioning and other stuff. |
| 66 | + |
| 67 | +```json |
| 68 | +{ |
| 69 | + "id": 54321, |
| 70 | + "sub": "1234567890", |
| 71 | + "name": "John Doe", |
| 72 | + "provider": "github", |
| 73 | + "emails": [ |
| 74 | + "john.doe@test.py" |
| 75 | + ], |
| 76 | + "avatar_url": "https://example.com/john.doe.png" |
| 77 | +} |
| 78 | +``` |
| 79 | + |
| 80 | +It looks easy for the `picture` and `display_name` attributes, but how to map `email` from `emails` or create a |
| 81 | +unique `identity` attribute. Well, that is where the callable functions come in handy. You can use the `lambda` function |
| 82 | +to map the attributes as follows. |
| 83 | + |
| 84 | +```python |
| 85 | +Claims( |
| 86 | + picture="image", |
| 87 | + display_name="avatar_url", |
| 88 | + email=lambda u: u.emails[0], |
| 89 | + identity=lambda u: f"{u.provider}:{u.sub}", |
| 90 | +) |
| 91 | +``` |
| 92 | + |
| 93 | +::: info NOTE |
| 94 | + |
| 95 | +Not all IDPs provide the `first_name` and the `last_name` attributes already joined as in the example above, or |
| 96 | +the email in a list. So you are given the flexibility using transformer function to map the attributes as you want. |
| 97 | + |
| 98 | +```mermaid |
| 99 | +flowchart LR |
| 100 | + IDPUserData("display_name string") |
| 101 | + FastAPIUserData("first_name string\nlast_name string") |
| 102 | + Transform[["transform into desired format"]] |
| 103 | + FastAPIUserData --> Transform |
| 104 | + Transform --> IDPUserData |
| 105 | +``` |
| 106 | + |
| 107 | +::: |
| 108 | + |
| 109 | +## User provisioning |
| 110 | + |
| 111 | +User provisioning refers to the process of creating, updating, and deleting user accounts within the OAuth2 IDP and |
| 112 | +synchronizing that information with your FastAPI application's database. There are two approaches to user provisioning |
| 113 | +and both require the user claims to be mapped properly for creating a new user or updating an existing one. |
| 114 | + |
| 115 | +### Automatic provisioning |
| 116 | + |
| 117 | +After successful authentication, you can automatically create a user in your application's database using the |
| 118 | +information obtained from the IDP. The user creation or update can be handled at the `callback` function of the |
| 119 | +[middleware](/integration/integration#oauth2middleware) as it is called when authentication succeeds. |
| 120 | + |
| 121 | +### Manual provisioning |
| 122 | + |
| 123 | +After successful authentication, redirect the user to a registration form where they can complete their profile. This |
| 124 | +approach is useful when there missing mandatory attributes in `request.user` for creating a user in your application's |
| 125 | +database. You need to define a route for provisioning and provide it as `redirect_uri`, so |
| 126 | +the [user context](/integration/integration#user-context) will be available for usage. |
| 127 | + |
| 128 | +::: info NOTE |
| 129 | + |
| 130 | +In both scenarios, it is recommended to use the `identity` attribute for uniquely identifying the user from the |
| 131 | +database. So if the application uses or plans to use multiple IDPs, make sure to include the `provider` attribute when |
| 132 | +calculating the `identity` attribute. |
| 133 | + |
| 134 | +::: |
| 135 | + |
| 136 | +<style> |
| 137 | +.info, .details { |
| 138 | + border: 0; |
| 139 | +} |
| 140 | +</style> |
0 commit comments