Skip to content

Problem: OIDC claim email is missor or has bad format #2818

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
XeryusTC opened this issue Mar 21, 2025 · 2 comments
Open

Problem: OIDC claim email is missor or has bad format #2818

XeryusTC opened this issue Mar 21, 2025 · 2 comments
Assignees

Comments

@XeryusTC
Copy link

XeryusTC commented Mar 21, 2025

Issue

Hello,

I'm trying to set up OpenID Connect but I am so far unsuccessful. Currently I'm getting the warning: level=error msg="claim 'email' missing or has bad format". The email claim should be present and correct, other OIDC SPs don't seem to have any problems. We're using the somewhat exotic NetIQ Access Manager as IDP.

Impact

Web-Frontend (what users interact with)

Installation method

Package

Database

Postgres

Browser

Firefox

Semaphore Version

2.13.0-75ffe9c-1742166024

Ansible Version

Logs & errors

level=error msg="claim 'email' missing or has bad format"

Manual installation - system information

OS: Debian 12
uname -a: Linux id-223 6.1.0-30-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.124-1 (2025-01-12) x86_64 GNU/Linux
Reverse proxy: nginx version: nginx/1.27.4

Configuration

"oidc_providers": {
        "nam": {
            "display_name": "Sign in with RUG SSO",
            "color": "red",
            "icon": "login",
            "provider_url": "https://signon.rug.nl/nidp/oauth/nam",
            "client_id": "redacted",
            "client_secret": "redacted",
            "redirect_url": "https://redacted/api/auth/oidc/nam/redirect",
            "scopes": ["openid", "profile", "email"],
            "username_claim": "preferred_username"
        }
    }

Additional information

No response

@ilbarone87
Copy link

Not sure if this can help, but I was having same issue setting the OIDC with another IDP called Zitadel and what fixed it for me was to make sure to include the user info in the ID token that helps clients to retrieve the scopes from it. Not always this is enabled by default.

@Rauks
Copy link

Rauks commented Apr 3, 2025

Hi,

I started encountering the same issue a few weeks ago, using Authelia as OIDC provider.
The issue is linked to a change in their release v4.39.0 (2025-03-16): https://github.com/authelia/authelia/releases/tag/v4.39.0.

  1. Changes that will require manual intervention in some scenarios:
    • The default claims for ID Tokens minted by the Authelia OpenID Connect 1.0 Identity Provider have changed.

Semaphore UI seems to fetch the claims from the ID Token instead of calling the UserInfo endpoint, and so is impacted.

I fixed it by using a custom claims policy: https://www.authelia.com/integration/openid-connect/openid-connect-1.0-claims/#restore-functionality-prior-to-claims-parameter

In Authelia configuration:

identity_providers:
  oidc:
    claims_policies:
      semaphore_claims_policy:
        id_token: ['groups', 'email', 'email_verified', 'alt_emails', 'preferred_username', 'name']

    clients:
      - client_id: 'semaphore'
        client_name: 'Semaphore'
        client_secret: '<super_secret>'
        claims_policy: 'semaphore_claims_policy'
        public: false
        authorization_policy: 'two_factor'
        redirect_uris:
          - 'https://<semaphore_host>/api/auth/oidc/authelia/redirect'
        scopes:
          - 'openid'
          - 'profile'
          - 'email'
        userinfo_signed_response_alg: 'none'

@fiftin fiftin self-assigned this Apr 19, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants