# Troubleshooting (https://docs.idra.zone/docs/troubleshooting) Fix common IdRa sign-in problems: redirect URI mismatch, invalid_client, not assigned, MFA required, wrong issuer, expired activation links and state errors. Each section starts with the text you'll see. For refused sign-ins, **Reports → System Log** records `app.access` with the reason. ## Redirect URI mismatch **You see:** **Sign-in error** with `invalid redirect uri`. The address bar ends in `/error?error=invalid_redirect`. **Cause:** your app sent a redirect URI that isn't registered on the app. Matching is exact, so `http://localhost:3001/callback` doesn't match `http://localhost:3000/callback`, and neither does a difference in path or a trailing slash. **Fix:** compare the `redirect_uri` your app sends with **Sign-in redirect URIs** on the app's **Sign On** tab, and make them identical. If saving the URI is refused with `Use https on a public host, or for local development http on localhost, 127.0.0.1 or [::1] with a port (…)`, use `http://localhost:3000/callback` locally and `https` on a public host in production. ## `invalid_client` The token endpoint answers `invalid_client` with one of these descriptions: | `error_description` | Cause | Fix | | --- | --- | --- | | `invalid client_secret` | Wrong secret, or it was replaced. | Select **Generate new secret** on **Sign On** and update your app. It's shown once. | | `client not found` | Wrong client ID, or a client ID from another organization. | Copy **Client ID** from **Connect your app**. | | `client registered for client_secret_basic cannot use none` | A Web Application sent no secret. | Set the client secret in your app's environment. | | `client registered for client_secret_basic cannot use client_secret_post` | The library sent the secret in the request body. | Send it as HTTP Basic, or change **Client authentication** on **Sign On**. | `openid-client` reports a wrong secret differently: `server responded with a challenge in the WWW-Authenticate HTTP Header`. The fix is the same as for `invalid client_secret`. A wrong client ID can also show up in the browser, before any token request: - **Sign-in error** with `client not found`. - If you're already signed in, **Access denied** with `This application is not registered with your organization.` ## Not assigned to the app **You see:** **Access to *app* denied** with `You are not assigned to this application.` **Cause:** neither the person nor any of their groups is assigned to the app. Being an administrator doesn't count: administrators need an assignment too. **Fix:** open the app in **Applications**. On **Assignments**, use **Assign to People** or **Assign to Groups**. To assign yourself, select **Assign me** under **Connect your app** on **Sign On**. Then start the sign-in again. ## MFA required **You see:** **Set up security methods** with `This resource requires additional verification.` right after a correct password. A person who already has a method is asked to verify with it. **Cause:** this is usually expected, not an error. The default rule for apps asks for MFA, and every administrator must have it. **Fix:** choose a method and finish it, and the sign-in carries on to the app. Choosing **Authenticator app** asks for the password again on **Verify with your password**. If your test account can't use MFA, change the app's rule on its **Authentication** tab; see [policies](https://docs.idra.zone/docs/admin/policies). Lost the authenticator? See [Lost your phone or authenticator](https://docs.idra.zone/docs/end-users/lost-authenticator). ## Wrong issuer The issuer is `https://.idra.team/api/auth`. Copy it from **Connect your app**. | What you see | Cause | Fix | | --- | --- | --- | | `404` with `{"error":"not_found"}` on discovery | The issuer is missing `/api/auth`. | Add it to the issuer. | | `404` with `{"error":"unknown_tenant"}` on discovery | The organization part of the address is wrong. | Use your organization's address. | | **Sign-in error** with `client not found`, with discovery working | The issuer is `https://idra.team/api/auth`, without your organization. That address answers discovery but doesn't have your app. | Use your organization's address. | ## Activation link expired **You see:** **This link has expired**. The address bar ends in `error=INVALID_TOKEN`. An activation link works once and lasts 7 days, so opening it a second time shows this too. If you've already set your password, just sign in. **Fix, for the first administrator:** the page says `To get a new one, open the confirmation link from your first email again.` On that page, select **Email me a new activation link**. **Fix, for someone you invited,** either: - They select **Get a new link** on that page, or **Forgot password?** on the sign-in page, enter their **Username** and select **Next**. If they haven't activated, IdRa emails a new activation link. - You open them in **Directory → People** and select **Activate**, which sends a new activation email. ### The first confirmation link The link from your first signup email has its own messages: | What you see | Cause | Fix | | --- | --- | --- | | **This link has expired** with **Start over** | Its 24 hours are up. | Select **Start over**. The form keeps your organization's name. | | **This link isn't valid** | A newer email replaced it, or the sign-up was cancelled. | Try the newest email, or select **Start over**. | ## `state` errors with Test sign-in **You see:** after **Test sign-in**, your app shows one of these on its callback page, or the browser can't reach it: | App | What you see | | --- | --- | | Next.js, Nuxt or Express | `Sign-in failed: invalid response encountered`, or you're sent to a new sign-in | | Flask or FastAPI | `Sign-in failed: mismatching_state: CSRF Warning! State not equal in request and response.` | | Go | `Sign-in failed: state mismatch` | | React SPA | `Sign-in failed: No matching state found in storage` | | Nothing running | The browser's `ERR_CONNECTION_REFUSED` | The app messages are from the code in the [quickstarts](https://docs.idra.zone/docs/quickstarts); your own app's wording may differ. **Cause:** this is expected. **Test sign-in** starts the sign-in from the console, so your app never stored the `state` it's being asked to check. If the address bar has a `code=`, IdRa's side works. **Fix:** nothing to fix in IdRa. To finish a sign-in, start it from your app's own sign-in link. If you get a state error when starting from your app, check that the session survives the round trip: use the same host throughout (`localhost` and `127.0.0.1` have separate cookies), and don't mark the session cookie `Secure` on `http`. Also, start only one sign-in at a time in a browser, because a second one can replace the first one's stored `state`. ## Still stuck Each [quickstart](https://docs.idra.zone/docs/quickstarts) ends with a troubleshooting table for its framework, and [OpenID Connect](https://docs.idra.zone/docs/admin/oidc) covers client types and tokens. End users can start with [Signing in](https://docs.idra.zone/docs/end-users/sign-in).