# You use a login service like Auth0 or Clerk

> If your app's login runs on a service such as Auth0, Clerk, Okta or Cognito, keep it and link STX accounts, or add STX as a login option inside the service. The OpenID Connect settings to enter, and what to ask STX for.

Source: https://docs.stxapp.io/oauth/sign-in-with-your-stx-account/login-vendor/

> **Availability.** Available on US demo now. Live access is coming soon in the US and Ontario. See [Environments](https://docs.stxapp.io/environments/).

If your app's login runs on a service such as Auth0, Clerk, Okta or Amazon Cognito, you have two choices.

| | Keep your login, link STX accounts | Add STX as a login option in the service |
| --- | --- | --- |
| Your users | Log in as they do today, then link their STX account once | Choose STX on your login screen, next to Google or Apple |
| Set up in the login service | Nothing | A custom OpenID Connect connection |
| Who talks to STX | Your server | The login service |
| Go to | [You have an app with its own accounts](/oauth/connect-your-stx-account/) | The rest of this page |

**If your app trades or reads account data for its users, the first choice is the simpler one**: your server holds the STX tokens, and nothing depends on what the login service passes on.

The rest of this page is the second choice. The login service does what [You're building a new app with no login yet](/oauth/sign-in-with-your-stx-account/) describes, for you: it sends the member to STX, where they register or log in, receives them back, and logs them in to your app.

How STX works as a login option inside a login service:

1. **Your login screen**: STX next to Google or Apple
2. **Your login service**: Starts the login for your app
3. **They register or log in**: On a page STX hosts, then back to the service
4. **Your app knows who they are**: From the service, as for any login

## Step by step

Two things follow from the service being the one that talks to STX:

- **The member's STX tokens go to the service, not to your app.** Your app can call the STX API for the member only if the service passes those tokens on to your server.
- **Errors from STX go to the service's callback.** What your app then sees depends on the service.

## Contact STX first

This is enabled per app, by STX. Contact [developer support](/support/) with:

- your app's name and logo, and the login service you use;
- the **login service's callback URL** for this connection. STX registers it and matches it exactly;
- the scopes you will request: `openid`, plus any member scopes from [Scopes](/oauth/scopes/);
- if you ask for a write scope, the addresses STX is called from: the login service's, for the token requests it makes, and your own server's, if it will call the STX API with the member's tokens.

You receive a `client_id` and a `client_secret`, and the STX base URL, written `$STX` below. See [Get demo access](/apps/overview/#get-demo-access) for how registration works.

## Settings to enter in the login service

Add a custom OpenID Connect connection. Services name it differently: a custom social connection, a generic or enterprise OIDC connection, an OIDC sign-in source. The values are the same.

| The service asks for | Value |
| --- | --- |
| Discovery URL, or issuer | `$STX/.well-known/openid-configuration`. The issuer is `$STX`, with no trailing slash |
| Client ID and client secret | The ones STX gives you |
| Scopes | `openid`, plus the member scopes you registered |
| Response type and grant | `code`, authorization code |
| PKCE | Required, with `S256` |
| Nonce | Optional. If the service sends one, STX returns it in the ID token |
| Token endpoint authentication | `client_secret_basic` (HTTP Basic). A secret sent in the form body (`client_secret_post`) is refused |
| ID token signing algorithm | `RS256`, with keys from `jwks_uri` |
| User id | The `sub` claim |
| Email | The `email` and `email_verified` claims |

If the service asks for each endpoint separately, copy them from the discovery document; see [Discovery](/oauth/discovery-and-errors/#discovery). The claims are described under [the ID token](/oauth/sign-in-with-your-stx-account/#2-read-the-id-token-from-the-token-response).

## Check with your login service

- **PKCE and HTTP Basic.** Both are required. A connection type that cannot send a PKCE challenge, or that can only send the client secret in the form body, will not work.
- **Access to the STX tokens.** Signing a member in needs only the ID token. To trade or read account data for them, your server also needs the member's STX access and refresh tokens, and login services differ on whether they hand those to you. If yours does not, keep your login and link STX accounts instead; see [You have an app with its own accounts](/oauth/connect-your-stx-account/).
- **Refresh.** STX issues a new refresh token on every refresh and the old one stops working. Whoever refreshes must store the new one each time.
- **Members still being verified.** A member who has not finished STX verification gets no tokens: STX returns `error=account_pending` to the **service's** callback, not to your app. How that reaches your app is up to the service; find out, and show a "finish verifying" state for it. See [Members still being verified](/oauth/members-being-verified/).
- **Members who decline.** In the same way, `error=access_denied` goes to the service's callback.