leptos/examples/sso_auth_axum
2024-01-19 18:02:22 -05:00
..
migrations sso_auth_session example (#2117) 2024-01-15 10:48:22 -08:00
public sso_auth_session example (#2117) 2024-01-15 10:48:22 -08:00
src update sso example 2024-01-19 18:02:22 -05:00
Cargo.toml update sso example 2024-01-19 18:02:22 -05:00
flake.lock sso_auth_session example (#2117) 2024-01-15 10:48:22 -08:00
flake.nix sso_auth_session example (#2117) 2024-01-15 10:48:22 -08:00
LICENSE sso_auth_session example (#2117) 2024-01-15 10:48:22 -08:00
Makefile.toml sso_auth_session example (#2117) 2024-01-15 10:48:22 -08:00
README.md sso_auth_session example (#2117) 2024-01-15 10:48:22 -08:00
sso.db sso_auth_session example (#2117) 2024-01-15 10:48:22 -08:00
style.css sso_auth_session example (#2117) 2024-01-15 10:48:22 -08:00

Leptos SSO Authenticated Email Display App with Axum

Overview

This project demonstrates various methods of implementing Single Sign-On (SSO) authorization using OAuth, specifically with the OAuth2 library. The primary focus is on the Authorization Code Grant flow.

Process Flow

  1. Initiating Sign-In: When a user clicks the 'Sign In With {THIRD PARTY SERVICE}' button, the request is sent to a server function. This function retrieves an authorization URL from the third-party service.

  2. CSRF Token Handling: During the URL fetch, a CSRF_TOKEN is generated and confirmed by the service to mitigate Cross-Site Request Forgery attacks. Learn more about CSRF here. This token is stored on our server.

  3. User Redirection: Post-login, users are redirected to our server with a URL formatted as follows:
    http://your-redirect-uri.com/callback?code=AUTHORIZATION_CODE&state=CSRF_TOKEN Note: Additional parameters like Scope and Client_ID may be included by the service.

  4. Token Acquisition: The 'code' parameter in the URL is not the actual service token. Instead, it's used to fetch the token. We verify the CSRF_TOKEN in the URL against our server's stored token for security.

  5. Access Token Usage: With a valid CSRF_TOKEN, we use the AUTHORIZATION_CODE in an HTTP Request to the third-party service. The response typically includes:

  • An access token
  • An expires_in value (time in seconds until token expiration)
  • A refresh token (used to renew the access token)
  1. Email Retrieval and Display: The access token allows us to retrieve the user's email. This email is then displayed in our Email Display App.

  2. Session Management: The expires_in value is sent to the client. The client uses this to set a timeout, ensuring that if the session is still active (the window hasn't been closed), it automatically triggers a token refresh when required.

Client Side Rendering

This example cannot be built as a trunk standalone CSR-only app. Only the server may directly connect to the database.

Server Side Rendering with cargo-leptos

cargo-leptos is now the easiest and most featureful way to build server side rendered apps with hydration. It provides automatic recompilation of client and server code, wasm optimisation, CSS minification, and more! Check out more about it here

Env Vars

Commands that run the program, cargo leptos watch, cargo leptos serve, cargo run etc... All need the following Environment variables G_AUTH_CLIENT_ID : This is the client ID given to you by google. G_AUTH_SECRET : This is the secret given to you by google. NGROK : this is the ngrok endpoint you get when you run ngrok http 3000

Ngrok Google Set Up

After running your app, run

ngrok http 3000

Then use google api's and services, go to credentials, create credentials, add your app name, and use the ngrok url as the origin and use the ngrok url with /g_auth as the redirect url. That will look like this https://362b-24-34-20-189.ngrok-free.app/g_auth Save you client ID and secret given to you by google. Use them as Envars when you run the program as below

REDIRECT_URL={ngrok_redirect_url} G_AUTH_CLIENT_ID={google_credential_client_id} G_AUTH_SECRET={google_credential_secret} {your command here...}
  1. Install cargo-leptos
cargo install --locked cargo-leptos
  1. Build the site in watch mode, recompiling on file changes
cargo leptos watch

Open browser on http://localhost:3000/

  1. When ready to deploy, run
cargo leptos build --release

Server Side Rendering without cargo-leptos

To run it as a server side app with hydration, you'll need to have wasm-pack installed.

  1. Edit the [package.metadata.leptos] section and set site-root to ".". You'll also want to change the path of the <StyleSheet / > component in the root component to point towards the CSS file in the root. This tells leptos that the WASM/JS files generated by wasm-pack are available at ./pkg and that the CSS files are no longer processed by cargo-leptos. Building to alternative folders is not supported at this time. You'll also want to edit the call to get_configuration() to pass in Some(Cargo.toml), so that Leptos will read the settings instead of cargo-leptos. If you do so, your file/folder names cannot include dashes.
  2. Install wasm-pack
cargo install wasm-pack
  1. Build the Webassembly used to hydrate the HTML from the server
wasm-pack build --target=web --debug --no-default-features --features=hydrate
  1. Run the server to serve the Webassembly, JS, and HTML
cargo run --no-default-features --features=ssr