docs(quickstart): userinfo fetch (#6492)

This commit is contained in:
Max Peintner 2023-09-06 11:38:20 +02:00 committed by GitHub
parent c8775c41e8
commit f7e7af0083
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

View File

@ -4,29 +4,60 @@ title: Quick start guide
import VSCodeFolderView from "../../../static/img/guides/quickstart/vscode1.png";
## Introduction
In this quick start guide, we will be learning some fundamentals on how to set up ZITADEL for user management and application security. Thereafter, we will secure a React-based Single Page Application (SPA) using ZITADEL.
The sample application allows users to securely log in to ZITADEL using the OIDC Proof Key for Code Exchange (PKCE) flow. This flow ensures that the authentication process is secure by using a code verifier and a code challenge, which are sent to ZITADEL to obtain an access token. The access token is then used by the app to access the userinfo endpoint to retrieve and display information about the logged-in user. The app also has a logout feature that allows users to end their session and clear their access token. Overall, the app provides a simple and secure way for users to authenticate and access protected resources within ZITADEL.
## ZITADEL terminology: instances, organizations, projects, users, roles, authorizations and apps
In ZITADEL, instances, organizations, projects, users, roles, and apps are the main components that make up the platform.
The order of creation for the above components would typically be as follows:
<ul>
<li><b>Instance</b>: An instance is a top-level entity in ZITADEL that represents a deployment of ZITADEL for a registered account. An instance can have one or more organizations.</li>
<li><b>Organization</b>: An organization is a logical separation within an instance that represents a company/organization and can have one or more projects. The default organization is the one that is provided at the start of the account registration process. Typically, an instance would have one organization, but in B2B scenarios, an instance would have more than one.</li>
<li><b>Project</b>: A project is a logical separation within an organization and is a container for apps, roles and authorization policies for the resources it contains.</li>
<li><b>Users</b>: Users are created at the organizational level and are granted access to the resources within projects. They can be assigned different roles, which define the permissions and privileges they have within the project.</li>
<li><b>Roles</b>: Roles are the sets of permissions and privileges that are assigned to users within a project.</li>
<li><b>Authorizations</b>: Authorization policies in ZITADEL are defined at the project level, which means that they apply to all the resources within the project. These policies are based on the roles that are assigned to users, and they determine the actions that users are allowed to perform within the project.</li>
<li><b>Apps</b>: Apps are the applications that are developed and managed within a project. They can be client apps that use the resources within the project, or they can be backend apps that provide the resources for other apps to use. The apps can use the OIDC or SAML protocol to authenticate users to access protected resources.</li>
<li>
<b>Instance</b>: An instance is a top-level entity in ZITADEL that
represents a deployment of ZITADEL for a registered account. An instance can
have one or more organizations.
</li>
<li>
<b>Organization</b>: An organization is a logical separation within an
instance that represents a company/organization and can have one or more
projects. The default organization is the one that is provided at the start
of the account registration process. Typically, an instance would have one
organization, but in B2B scenarios, an instance would have more than one.
</li>
<li>
<b>Project</b>: A project is a logical separation within an organization and
is a container for apps, roles and authorization policies for the resources
it contains.
</li>
<li>
<b>Users</b>: Users are created at the organizational level and are granted
access to the resources within projects. They can be assigned different
roles, which define the permissions and privileges they have within the
project.
</li>
<li>
<b>Roles</b>: Roles are the sets of permissions and privileges that are
assigned to users within a project.
</li>
<li>
<b>Authorizations</b>: Authorization policies in ZITADEL are defined at the
project level, which means that they apply to all the resources within the
project. These policies are based on the roles that are assigned to users,
and they determine the actions that users are allowed to perform within the
project.
</li>
<li>
<b>Apps</b>: Apps are the applications that are developed and managed within
a project. They can be client apps that use the resources within the
project, or they can be backend apps that provide the resources for other
apps to use. The apps can use the OIDC or SAML protocol to authenticate
users to access protected resources.
</li>
</ul>
The order of creation for the above components may vary depending on the specific needs and requirements of the organization.
@ -242,6 +273,7 @@ We will now create an application in the project, which will allow our React cli
![Add Application](/img/guides/quickstart/50.png)
### 8. Obtain ClientId and OIDC endpoints for your application {#referred1}
You will need the ClientId and the OIDC endpoints (issuer and userinfo) when building your React application. The issuer URL is the base URL for the OIDC provider and includes the path to the OIDC discovery document, which contains information about the OIDC provider, including the authorization and token endpoints. By providing the issuer URL, you can use the OIDC library to automatically determine the endpoints for these requests.
The authorization endpoint is used to initiate the authorization process, the token endpoint is used to exchange authorization codes for access tokens, and the userinfo endpoint is used to retrieve information about the user. You need an access token to access the userinfo endpoint and other protected resources.
@ -272,7 +304,7 @@ And with that, configuring ZITADEL for our application is complete. Now we can m
10. When the user wants to log out, the React app sends a request to the ZITADEL logout endpoint, which clears the access token and ends the user's session.
11. The user will be redirected to the login page of the app.
***The scope of this application for this quick start guide is limited to user authentication and doesn't include role-based authentication, even though we previously discussed adding roles and users.***
**_The scope of this application for this quick start guide is limited to user authentication and doesn't include role-based authentication, even though we previously discussed adding roles and users._**
### 2. Prerequisites
@ -282,18 +314,19 @@ To install React, you will need to have Node.js installed on your system. You ca
To install Visual Studio Code, go to their [website](https://code.visualstudio.com/) and download and install the version for your operating system.
### 3. Development
#### 1. Create project
1. Open a new terminal window in Visual Studio Code.
2. Navigate to the folder where you want to create the React app.
3. Run the following command to create a new React app named "react-oidc-zitadel":
``` npx create-react-app react-oidc-zitadel ```
`npx create-react-app react-oidc-zitadel`
4. Navigate to the "react-oidc-zitadel" folder:
``` cd react-oidc-zitadel ```
`cd react-oidc-zitadel`
This will create the following files in your project:
@ -301,8 +334,7 @@ This will create the following files in your project:
5. The dependencies for this project include react-router-dom and oidc-client-ts. To include them in your React application, you will need to run the following command in your terminal:
``` npm install react-router-dom oidc-client-ts ```
`npm install react-router-dom oidc-client-ts`
#### 2. Add source files
@ -377,12 +409,12 @@ export default App;
The App.js file is the root component of the React app that initializes the OIDC flow and manages the user's session. It does this by:
- Importing the necessary libraries and components from the dependencies, including the ```oidc-client-ts``` library, the ```authConfig``` file with the OIDC configuration values, and the Login and Callback components.
- Initializing a new ``UserManager`` instance with the OIDC configuration values from the authConfig file. The ``` UserManager``` instance manages the OIDC flow and stores the user's session information.
- Defining two functions: ```authorize``` and ```clearAuth```. The ```authorize``` function initiates the OIDC flow when the user clicks the ```login``` button, while the ```clearAuth``` function ends the user's session when the user clicks the ```logout``` button.
- Defining two state variables: ```authenticated``` and ```userInfo```. The authenticated variable is a boolean that indicates whether the user is authenticated or not, while the ```userInfo``` variable stores the user's information when they are authenticated.
- Using the ```useEffect``` hook to retrieve the user's session information from the ```UserManager``` instance and updating the ```authenticated``` and ```userInfo``` state variables accordingly.
- Defining the routes for the app using the ```react-router-dom``` library, including the ```/``` and ```/callback``` routes for the login and callback pages, respectively. The ```Login``` and ```Callback``` components handle the login and callback processes, respectively.
- Importing the necessary libraries and components from the dependencies, including the `oidc-client-ts` library, the `authConfig` file with the OIDC configuration values, and the Login and Callback components.
- Initializing a new `UserManager` instance with the OIDC configuration values from the authConfig file. The ` UserManager` instance manages the OIDC flow and stores the user's session information.
- Defining two functions: `authorize` and `clearAuth`. The `authorize` function initiates the OIDC flow when the user clicks the `login` button, while the `clearAuth` function ends the user's session when the user clicks the `logout` button.
- Defining two state variables: `authenticated` and `userInfo`. The authenticated variable is a boolean that indicates whether the user is authenticated or not, while the `userInfo` variable stores the user's information when they are authenticated.
- Using the `useEffect` hook to retrieve the user's session information from the `UserManager` instance and updating the `authenticated` and `userInfo` state variables accordingly.
- Defining the routes for the app using the `react-router-dom` library, including the `/` and `/callback` routes for the login and callback pages, respectively. The `Login` and `Callback` components handle the login and callback processes, respectively.
2. Create a folder named components in the src directory. Create two files named Login.js and Callback.js.
@ -417,7 +449,8 @@ const Login = ({ auth, handleLogin, userManager }) => {
export default Login;
```
The ```/``` route corresponds to the login page, which is rendered by the Login component. The Login(Login.js) component is a functional component that displays the login button and calls the ```handleLogin``` function (which corresponds to the ```authorize``` function defined in the App component) when the button is clicked. This initiates the OIDC flow by redirecting the user to the authorization endpoint.
The `/` route corresponds to the login page, which is rendered by the Login component. The Login(Login.js) component is a functional component that displays the login button and calls the `handleLogin` function (which corresponds to the `authorize` function defined in the App component) when the button is clicked. This initiates the OIDC flow by redirecting the user to the authorization endpoint.
4. Paste the following code to Callback.js.
@ -451,6 +484,20 @@ const Callback = ({ auth, setAuth, userManager, userInfo, setUserInfo, handleLog
}).catch((error) => {
setAuth(false);
});
} else if (auth === true && !userInfo) {
userManager.getUser().then((user) => {
const access_token = user.access_token;
fetch(authConfig.userinfo_endpoint, {
headers: {
Authorization: `Bearer ${access_token}`,
},
})
.then((response) => response.json())
.then((userInfo) => {
setUserInfo(userInfo);
});
});
}
}, [auth, userManager, setAuth]);
@ -478,7 +525,7 @@ const Callback = ({ auth, setAuth, userManager, userInfo, setUserInfo, handleLog
export default Callback;
```
The ```/callback``` route corresponds to the callback page, which is rendered by the Callback(Callback.js) component. The Callback component is also a functional component that handles the callback from the authorization server after the user logs in. It retrieves the authorization code from the URL, exchanges it for an access token and id token, and retrieves the user's information from the userinfo endpoint. It also sets the ```authenticated``` and ```userInfo``` state variables in the App(App.js) component and displays the ```logout``` button. When the ```logout``` button is clicked, the ```clearAuth``` function is called and the user's session is ended. The ```clearAuth``` function is defined in the App component and is called with no arguments. It initiates the end session flow by redirecting the user to the end session endpoint.
The `/callback` route corresponds to the callback page, which is rendered by the Callback(Callback.js) component. The Callback component is also a functional component that handles the callback from the authorization server after the user logs in. It retrieves the authorization code from the URL, exchanges it for an access token and id token, and retrieves the user's information from the userinfo endpoint. It also sets the `authenticated` and `userInfo` state variables in the App(App.js) component and displays the `logout` button. When the `logout` button is clicked, the `clearAuth` function is called and the user's session is ended. The `clearAuth` function is defined in the App component and is called with no arguments. It initiates the end session flow by redirecting the user to the end session endpoint.
5. Create a new file in the src folder named authConfig.js and paste the following code to it.
@ -500,14 +547,15 @@ const authConfig = {
export default authConfig;
```
The authConfig.js file exports an object with configuration values for the OIDC flow. These values are used to initialize the ```UserManager``` instance in the App component. The configuration values include the:
- authority (the URL of the authorization server). ***Dont forget to replace the ```authority``` value with the “issuer URL” that you obtained from this [step](#referred1).***
- client_id (the unique identifier for the client application). ***Dont forget to replace the ```client_id``` with your “ClientId” that you obtained from this [step](#referred1).***
The authConfig.js file exports an object with configuration values for the OIDC flow. These values are used to initialize the `UserManager` instance in the App component. The configuration values include the:
- authority (the URL of the authorization server). **_Dont forget to replace the `authority` value with the “issuer URL” that you obtained from this [step](#referred1)._**
- client_id (the unique identifier for the client application). **_Dont forget to replace the `client_id` with your “ClientId” that you obtained from this [step](#referred1)._**
- redirect_uri (the URL to redirect to after the authorization flow is complete)
- response_type (the type of response expected from the authorization server)
- scope (the permissions requested from the user)
- post_logout_redirect_uri (the URL to redirect to after the user logs out)
- userinfo_endpoint (the URL of the endpoint to retrieve the user's information). ***Dont forget to replace the ```userinfo_endoint``` with your “userinfo_endpoint” that you obtained from this [step](#referred1).***
- userinfo_endpoint (the URL of the endpoint to retrieve the user's information). **_Dont forget to replace the `userinfo_endoint` with your “userinfo_endpoint” that you obtained from this [step](#referred1)._**
- response_mode (the method to use to send the authorization response)
- code_challenge_method (the method to use to generate the code challenge).
@ -556,8 +604,7 @@ In the PKCE flow, the code verifier is a random string generated by the client a
}
```
7. Go to index.js and replace ```import './index.css';``` with ```import './style.css'```. Your index.js file should look like this:
7. Go to index.js and replace `import './index.css';` with `import './style.css'`. Your index.js file should look like this:
[src/index.js](https://github.com/zitadel/react-user-authentication/blob/main/src/index.js)
@ -583,8 +630,8 @@ reportWebVitals();
### 4. Running the application
1. Run ```npm start``` to start the development server.
2. Open your browser and navigate to ```http://localhost:3000/``` to view the app.
1. Run `npm start` to start the development server.
2. Open your browser and navigate to `http://localhost:3000/` to view the app.
3. You will see the login page, which is the landing page of the app, when you run the application. Click on the “Please log in” button.
![Login](/img/guides/quickstart/login1.png)
@ -613,10 +660,8 @@ reportWebVitals();
![Redirect](/img/guides/quickstart/login6.png)
And this brings us to the end of this quick start guide!
This tutorial covered how to configure ZITADEL and how to use React to build an app that communicates with ZITADEL to access secured resources.
We hope you enjoyed the tutorial and encourage you to check out the ZITADEL [documentation](https://zitadel.com/docs) for more information on how to use the ZITADEL platform to its full potential. Thanks for joining us!