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.
Lost the authenticator? See Lost your phone or authenticator.
Wrong issuer
The issuer is https://<your-org>.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; 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 ends with a troubleshooting table for its framework, and OpenID Connect covers client types and tokens. End users can start with Signing in.