Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add oauth docs #847

Open
wants to merge 7 commits into
base: master
Choose a base branch
from
Open

Add oauth docs #847

wants to merge 7 commits into from

Conversation

bcbogdan
Copy link
Contributor

@bcbogdan bcbogdan commented Sep 17, 2024

General TODO

  • OAuth2 flows diagrams
  • Diagrams for guides
  • Use the AppInfoForm and CoreInjector in every code snippets that show urls
  • Add a different code tabs abstraction (other than BackendSDKTabs) that allows more languages
  • Explain where SuperTokens Tokens are used compared to OAuth2 Tokens
  • Explain how to use libraries for external session handling
  • Add section about custom ui
  • Add instructions to configure custom claims
  • Add guide on how to manually verify tokens
  • Add scopes custom guide
  • how would users handle the prompt=login query param (custom UI), and which other query param should be handled?
  • mention in all recipes for custom ui in mobile app case that if users want to reuse web ui in mobile app login, we should redirect them to OAuth recipe

Code Samples/Instructions @porcellus

  • Access token validation instructions
  • Override access token
  • Override id token
  • Override granted scopes
  • create client API Response shape
  • Generate access token request shape
  • Custom UI requirements
  • Exchange oauth2 access token for supertokens session token

Copy link

netlify bot commented Sep 17, 2024

Deploy Preview for admiring-bhabha-7b1be9 ready!

Name Link
🔨 Latest commit e507130
🔍 Latest deploy log https://app.netlify.com/sites/admiring-bhabha-7b1be9/deploys/66fba6852be96c0008a71d05
😎 Deploy Preview https://deploy-preview-847--admiring-bhabha-7b1be9.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

v2/oauth/introduction.mdx Outdated Show resolved Hide resolved
v2/oauth/introduction.mdx Outdated Show resolved Hide resolved
v2/oauth/introduction.mdx Outdated Show resolved Hide resolved
v2/oauth/introduction.mdx Outdated Show resolved Hide resolved
v2/oauth/introduction.mdx Outdated Show resolved Hide resolved
import BackendSDKTabs from "/src/components/tabs/BackendSDKTabs"


# Reuse website login for desktop and mobile apps
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure how this page is helpful. The flow for mobile / desktop is very different compared to web apps from the point of view of which lib to use, how to use that lib etc. Once again, we will have to find example tutorial for mobile / desktop apps and link to those, and then add additional comments explaining to users how that tutorial would change in the context of supertokens.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should expand this and provide more concrete guidance on how to achieve this, but the main point of this (i.e.: you are re-using web sign-in for mobile) is correct.

// You will have to initialize the OAuth2Client recipe
// for each of your previously created clients
OAuth2Client.init({
clientId: '<CLIENT_ID>',
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

users will have multiple clients, so they need to be added here in an array?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will have to be updated for the current version types, I think we still had a single clientId/secret pair when @bcbogdan was writing it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

resolved

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I dont think this is resolved. It still has just one client id and secret.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe you were on a previous version. It's an array with a providerConfigs option

v2/oauth/multiple-frontends-with-a-single-backend.mdx Outdated Show resolved Hide resolved
v2/oauth/multiple-frontends-with-a-single-backend.mdx Outdated Show resolved Hide resolved
</TabItem>

</BackendSDKTabs>

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

missing step of initing the oauthprovider recipe in the oauth provider frontend application.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you can extract the part of setting up the OAuth provider as its own page. So after the Introduction section, you can have a page (before the use cases section) that says "Setting up OAuth provider" which talks about initing oauthprovider on the backend and frontend of the auth server, and talking about that there. So that the use cases only focus on the clients and dont have to talk about oauth provider setup again and again.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One more missing part here is that there is no custom UI docs for how to setup an oauth provider with a custom UI instead of using our pre built ui

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

resolved

Comment on lines 100 to 101
"authorize_url": "^{form_apiDomain}/^{form_apiBasePath}/oauth/auth",
"token_fetch_url": "^{form_apiDomain}/^{form_apiBasePath}/oauth/token"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

^{form_apiBasePath} already adds a /, so you need to do "^{form_apiDomain}/^{form_apiBasePath}oauth/auth

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

resolved

</BackendSDKTabs>


### Configure the Authorization Service Frontend
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for pre built UI, you also have to tell users to add the prebuiltui component in case of react being used.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

resolved


In your `frontend` applications you will have to add a login action that will direct the user to the authentication page.

The user should first be redirected to the `backend` authentication endpoint that was defined during the previous step.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Its a bit unclear, which url exactly?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

resolved

You can use the [AuthLib](https://docs.authlib.org/) library.
Just follow these [instructions](https://docs.authlib.org/en/latest/client/oauth2.html) and implement it in your `backend`.

</TabItem>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

need to add content for other languages as well

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

resolved

</OAuthBackendTabs>


## 5. Update the login flow in your frontend applications
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this step correctly apply to all the languages mentioned for the previous step?

Just follow [the instructions](https://commerce.nearform.com/open-source/react-native-app-auth/docs/usage/config) setup your application.
The configuration parameters can be determined based on the response that we received on **step 2**, when we created the **OAuth2 Client**.

- `issuer` corresponds to the endpoint of the **Authorization Service** `^{form_apiDomain}`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think the issuer that we use is apidomain + apibasepath. Please confirm with @porcellus

In each of your individual `applications` you will have to setup up logic for handling the **OAuth 2.0** authentication flow.
We recommend using a generic **OICD** or **OAuth** library in order to do this.

<OAuthMobileTabs>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for mobile flows, we also need to mention to have a prompt=login query param added to the authorization url during redirection. You will have to see how to do this for each of the mobile app docs.

import React from "react";
let Tabs = require("@theme/Tabs").default;

export default function OAuthMobileTabs(props: any) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We already have a component to render the mobile code tabs. Please reuse that.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think I can use that. It's a subtabs component. I've updated the oauth tabs to match the options that we expose in those subtabs

OAuth2Provider.init()
```

3. Update the **Session** recipe initialization to use `header` authentication.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is not needed to do in the authorization server frontend. This step is needed in the application frontend

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

resolved

Comment on lines 273 to 278
In your `frontend` applications you will have to add a login action that will direct the user to the authentication page.

The user should first be redirected to the `backend` login endpoint.
There the `backend` will redirect the user to the actual [**Authorization Service**](/docs/oauth/introduction#authorization-service) login UI.
After the user has logged in they will be redirected to the `backend` callback URL.
Then the authentication session will be created and the `backend` will send it to the user agent as a cookie.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You should first mention that you need to setup supertokens session in the frontend application here, and you can do that by following https://supertokens.com/docs/session/quick-setup/frontend.

Then talk about setting it to header based auth, and say why we need to do it - cause each of these frontends will be third party domains to the backend, and third party cookies are not allowed by browsers like safari.

Then we need to talk about using an oauth lib for the framework and setting the various values in that.

Then finally, when the oauth login is done, we can tell users to call some API (which one - need to have the curl command) which will exchange the oauth tokens for a supertokens session?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

resolved

Comment on lines 27 to 33
The **OAuth2 recipes** are available only when using the **SuperTokens Managed Service**. This feature is not included in the **Self-Hosted** version.

Also, the feature at the moment is supported, on the backend, just by the following **SDKs**:
- `supertokens-node`
- All our frontend SDKs

Additionally, our **OAuth2** implementation does not support magic links based login flows right now.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The **OAuth2 recipes** are available only when using the **SuperTokens Managed Service**. This feature is not included in the **Self-Hosted** version.
Also, the feature at the moment is supported, on the backend, just by the following **SDKs**:
- `supertokens-node`
- All our frontend SDKs
Additionally, our **OAuth2** implementation does not support magic links based login flows right now.
There are a few limitations to the OAuth recipe:
- It's only available for the **SuperTokens Managed Service**. This feature is not included in the **Self-Hosted** version.
- Only `supertokens-node` backend SDK supports it as of yet. So if you are using our golang or python SDK, you will have to wait, or else you could switch to using our node SDK.
- We do not support magic link based login, however, you can switch to email / SMS OTP instead which offers the same level of security.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

resolved

:::info

This token is different from the **SuperTokens Session Access Token**.
The latter is used in the **OAuth 2.0** authentication flows when you set the `authMode: 'header'` option in the `Session` recipe.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The latter is used in the **OAuth 2.0** authentication flows when you set the `authMode: 'header'` option in the `Session` recipe.
The latter is used in the **OAuth 2.0** authentication flows to maintain a session between the authorization frontend and the authorization backend server.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

resolved

:::info

This token is different from the **SuperTokens Session Refresh Token**.
The latter is used in the **OAuth 2.0** authentication flows when you set the `authMode: 'header'` option in the `Session` recipe.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The latter is used in the **OAuth 2.0** authentication flows when you set the `authMode: 'header'` option in the `Session` recipe.
The latter is used in the **OAuth 2.0** authentication flows to maintain a session between the authorization frontend and the authorization backend server.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

resolved


<img src="/img/oauth/authorization-code-flow.png" alt="Authorization Code Grant"/>

This flow is best suited for **web applications** where the [**Client**](/#client) can securely store a client secret (for example in the application's backend).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But if we use with PKCE, then there is no need for a client secret. So this can be a bit misleading.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

resolved

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All security guidance on PKCE explicitly state that it is not intended to replace the client-secret, so that's something we should take care to not suggest.

# You will have to run this for each one of your applications
# Adjust the client_name and redirect_uri based on that
curl -X POST ^{coreInjector_uri_without_quotes}/recipe/oauth2/admin/clients \
-H "Content-Type: application/json" \
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

missing API key. Please see how other snippets to curl have the API key. Our component auto adds the api key if the user is logged into their dashboard

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

resolved

</TabItem>

</BackendSDKTabs>

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So this would apply mainly to the use case of multiple frontends with common backend, right?

Comment on lines +128 to +138
1. Add the import statement for the recipe.

```typescript
import OAuth2Provider from "supertokens-node/recipe/oauth2provider";
```

2. Update the list of recipes with the new initialization step.

```tsx
OAuth2Provider.init()
```
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

normally we show the full supertokens.init here and highlight the important parts. FOr some people it can get confusing where to do OAuth2Provider.init() if they do not really understand the recipe thing we have and just copy / paste docs blindly

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we show the entire init page it might get confusing for them since we can't really know what recipes they already have initialized. Also if they don't understand where recipe init happens then we can't expect them to follow the OAuth2 session guides.

Just keep in mind to generate a new one when it expires.

The service that will receive the request which includes the **OAuth2 Access Token** will have to verify it.
To see a detailed example of how to do this please check our [separate guide](/docs/oauth/customizations/verfiy-tokens).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fix link

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

resolved

import AppInfoForm from "/src/components/appInfoForm"
import TabItem from '@theme/TabItem';

# Multiple Frontend Domains Using a Single Backend
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The title here and the title in the sidebar are not consistent. Please make sure consistency for all pages

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

resolved

// You will have to initialize the OAuth2Client recipe
// for each of your previously created clients
OAuth2Client.init({
clientId: '<CLIENT_ID>',
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I dont think this is resolved. It still has just one client id and secret.

title: Create an authentication provider
hide_title: true
---

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this page relevant? Cause its not in the sidebar

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

resolved

@bcbogdan bcbogdan force-pushed the feat/oauth branch 8 times, most recently from 0ddede6 to 36b67a3 Compare September 30, 2024 12:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants