-
Notifications
You must be signed in to change notification settings - Fork 71
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
base: master
Are you sure you want to change the base?
Add oauth docs #847
Conversation
✅ Deploy Preview for admiring-bhabha-7b1be9 ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
9cb4848
to
9308ff6
Compare
import BackendSDKTabs from "/src/components/tabs/BackendSDKTabs" | ||
|
||
|
||
# Reuse website login for desktop and mobile apps |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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>', |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
resolved
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
</TabItem> | ||
|
||
</BackendSDKTabs> | ||
|
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
resolved
"authorize_url": "^{form_apiDomain}/^{form_apiBasePath}/oauth/auth", | ||
"token_fetch_url": "^{form_apiDomain}/^{form_apiBasePath}/oauth/token" |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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> |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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?
v2/oauth/reuse-website-login.mdx
Outdated
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}` |
There was a problem hiding this comment.
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
v2/oauth/reuse-website-login.mdx
Outdated
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> |
There was a problem hiding this comment.
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) { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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` 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. |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
resolved
v2/oauth/introduction.mdx
Outdated
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 was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
resolved
v2/oauth/introduction.mdx
Outdated
:::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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
resolved
v2/oauth/introduction.mdx
Outdated
:::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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
resolved
v2/oauth/introduction.mdx
Outdated
|
||
<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). |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
resolved
There was a problem hiding this comment.
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" \ |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
resolved
</TabItem> | ||
|
||
</BackendSDKTabs> | ||
|
There was a problem hiding this comment.
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?
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() | ||
``` |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fix link
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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>', |
There was a problem hiding this comment.
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 | ||
--- | ||
|
There was a problem hiding this comment.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
resolved
0ddede6
to
36b67a3
Compare
36b67a3
to
6aa257b
Compare
General TODO
AppInfoForm
andCoreInjector
in every code snippets that show urlsBackendSDKTabs
) that allows more languagesCode Samples/Instructions @porcellus
create client
API Response shape