Supabase Custom OIDC: Battle.net JWKS fails ID token verification (illegal base64 data)

[Razorgon007]

Problem

I'm integrating Blizzard Battle.net authentication with Supabase Auth using a Custom OIDC provider.

The OAuth flow reaches the Supabase callback endpoint, but authentication fails during server-side ID-token signature verification.

Exact error from Supabase Auth logs:

failed to verify ID token: failed to verify signature: fetching keys oidc: failed to decode keys: got Content-Type = application/json, but could not unmarshal as JSON: illegal base64 data at input byte 7

The callback returns HTTP 500. The application subsequently receives error=server_error and error_code=unexpected_failure.

Public OIDC endpoints

• Issuer: https://oauth.battle.net/
• Discovery: https://oauth.battle.net/.well-known/openid-configuration
• JWKS: https://oauth.battle.net/jwks/certs

Configuration

• Supabase Auth: Custom OIDC provider
• Configuration: Auto-discovery
• Scopes: openid, wow.profile
• Allow users without email: Enabled
• Client ID and secret: Configured (not shared here)

Troubleshooting already completed

1. Verified the issuer and OIDC discovery URL.
2. Verified the OAuth client ID and registered callback URL.
3. Confirmed the authorization flow reaches Supabase's callback endpoint.
4. Inspected Supabase Auth logs and identified the HTTP 500 failure.
5. Tested using only the openid scope; the same error occurred.
6. Inspected manual OIDC configuration, but did not change the existing setup.
7. Examined Blizzard's public JWKS response.

Suspected cause

The public Blizzard JWKS appears to contain RSA modulus values using standard Base64 characters such as + and /, rather than the Base64URL encoding normally expected for JWK RSA parameters.

This may explain the decoding error, but I have not conclusively established the root cause.

Questions

1. Is this a known compatibility issue between Supabase Custom OIDC and Blizzard Battle.net?
2. Does Supabase Auth support a configuration option or library update that handles this JWKS encoding?
3. Is there a supported, secure workaround that preserves ID-token signature verification and handles JWKS key rotation?
4. Has anyone successfully integrated Battle.net with Supabase Auth using Custom OIDC?

I'd prefer to avoid implementing a custom authentication backend if a supported solution exists.

Any guidance would be greatly appreciated. Thank you!

[GaryAustin1]

Two AI's say the Blizzard endpoint is not returning keys in a json array required by 7517 standard and so Supabase is complaining about that. Note I did not give your error and both actually seem to have polled an endpoint to determine the malformed data.

There are no settings on this.

Could not find any issue or comments on the web though at all.

[Razorgon007]

Hi Gary, thanks for taking the time to look into this! this has been a strain

I inspected Blizzard's public JWKS endpoint and noticed that some RSA modulus values contain standard Base64 characters (+ and /), rather than the Base64URL encoding normally required by the JWK specification.

This seems consistent with the Supabase Auth error:

failed to decode keys: ... illegal base64 data at input byte 7

I suspect this may be a compatibility issue between Blizzard's JWKS format and the OIDC verification library used by Supabase Auth, although I haven't conclusively confirmed the root cause.

Do you know whether Supabase supports a way to normalize these public keys before verification, or whether this would require a change to the underlying Auth implementation?

I'd prefer to keep using Supabase's built-in authentication rather than introduce a custom OAuth backend, particularly to preserve proper signature verification and key rotation.

Thanks again for your help!

[GaryAustin1]

You would need to have your own intermediary function to convert the battle.net info to the "standard" format Supabase expects. There are no hooks that I know of.

[Razorgon007]

Thanks for this Gary

Before I investigate building an intermediary, I found that Supabase supports separate generic OAuth2 and OIDC provider types.

Would using the generic OAuth2 provider with Blizzard's authorization, token, and userinfo endpoints avoid the JWKS decoding issue, or is there a reason that approach wouldn't be suitable?

I'm trying to find the simplest supported and secure solution before adding another service.

Hopefully then can get this sorted and stop annoying you :D

Appreciate your help!

[GaryAustin1]

Sorry I don't use these methods myself so have to feel for work arounds without "googling".

[AZapata27]

Your suspicion is right, and you can pin it to the byte. "input byte 7" is the + in the first key's n (ALI7m99+OTGF…). JWK RSA parameters are Base64urlUInt (RFC 7518 §6.3.1.1): URL-safe alphabet, no padding, no leading zero octets. Blizzard's n values use + and /, end in = and start with a sign byte (A…), which is what BigInteger.toByteArray() plus a standard Base64 encoder produces.

Supabase Auth verifies custom OIDC ID tokens with go-oidc, whose RemoteKeySet parses the JWKS through go-jose, and go-jose decodes every JWK byte field with base64.RawURLEncoding (encoding.go#L167). One bad key fails the whole set, and the error gets wrapped in custom_oauth.go#L199-L208. I reproduced your exact message with go-oidc v3.21 / go-jose v4.1.6 against the live https://oauth.battle.net/jwks/certs. go-oidc has closed this twice as a provider bug (#193, #422), so no lenient mode is coming from that side, and the custom provider config has nothing for it either: the only OIDC-specific options are discovery_url and skip_nonce_check (docs).

What does work with what's shipped is registering Battle.net as a custom OAuth2 provider instead (Manual configuration in the Dashboard, or provider_type: 'oauth2' via the admin API) with https://oauth.battle.net/authorize, /token and userinfo_url: https://oauth.battle.net/userinfo. That path never looks at the ID token: CustomOAuthProvider.GetUserData goes straight to userinfo with the access token (custom_oauth.go#L72-L74) and the identity is keyed on the sub it returns. You give up the signature check, but you aren't depending on it: the code is exchanged at Blizzard's token endpoint with your client secret over TLS and userinfo is called with the resulting access token, the same trust model as any plain-OAuth2 provider Supabase supports. Keep "allow users without email" on, and add battletag to custom_claims_allowlist if you want it on the identity. I haven't run this end to end with a Battle.net client, so treat it as read from the code rather than tested.

The real fix is on Blizzard's side (base64url in the JWKS); worth a ticket on their developer portal, since every go-jose based consumer will hit this.

[Razorgon007]

Hi @AZapata27,

Thank you for the detailed investigation, did a test as you suggested with generic OAuth2 workaround today

Configuration:

• Separate Supabase Custom OAuth2 provider using manual configuration.
• Blizzard authorization, token and UserInfo endpoints.
• JWKS URI left empty.
• Scope: wow.profile.
• Allow users without email enabled.
• Existing Blizzard client credentials and registered Supabase callback.

Results so far:

• Supabase accepted and enabled the OAuth2 provider without a JWKS URI.
• Our FlutterFlow application successfully initiated an authorization request using custom:battlenet-oauth2.
• Supabase received a callback returning HTTP 302.
• Supabase Auth logs recorded an action: login audit event with provider: custom:battlenet-oauth2.
• We found no recurrence of the previous JWKS decoding error in the logs inspected.
• However, no new Battle.net user appeared in Authentication → Users.
• We have not yet confirmed that FlutterFlow received a valid Supabase session.

Our FlutterFlow custom action currently launches the Supabase authorization URL in an external browser. We suspect the session handoff or redirect handling may need attention, but haven't established the cause.

Questions:

1. Does the Supabase login audit event indicate that the OAuth2 code exchange and UserInfo retrieval succeeded, or can that event appear before a usable session is established?
2. Is there a recommended way to verify the returned OAuth2 identity and session?
3. Are there any additional provider settings or claims we should check?

We're also evaluating Supabase email/password authentication with separate Blizzard account linking as an alternative.

Thanks again for your help. Your investigation has allowed us to get further than our original OIDC setup

[AZapata27]

Good news: that action: login event is written inside the same DB transaction that creates (or finds) the user and its identity, right after the code exchange and the userinfo call succeeded (external.go#L457). Nothing else logs it. So the user is there; what went missing is only the session on the FlutterFlow side.

Easiest way to see it, in the SQL editor:

select u.id, u.created_at, i.identity_data
from auth.identities i join auth.users u on u.id = i.user_id
where i.provider = 'custom:battlenet-oauth2';

identity_data is the raw userinfo (sub, id, battletag…). In the Users list that row has an empty email column, which is easy to scroll past. The actor_id in the audit event is the same user id.

On the session: that 302 is Supabase redirecting to your redirectTo (or the Site URL if you didn't pass one) with the tokens in the URL fragment (implicit flow) or a ?code= to exchange (PKCE). Since you open the auth URL in an external browser, the redirect lands in that browser, not in your app. You need a deep link to your app as redirectTo, added to the Redirect URLs allow list, and the app has to catch it and hand the URL to the Supabase client (getSessionFromUrl in supabase_flutter). One thing to keep in mind: an error also ends in a 302, with #error=... in the fragment, so when in doubt check the Location header in the logs.

Settings: nothing else needed. If you want the BattleTag on the identity, add battletag to the provider's custom_claims_allowlist.

[Razorgon007]

Hi @AZapata27,

First, thank you again for your help. Your suggestion to switch from Custom OIDC to manually configured Custom OAuth2 has made a real difference, its been a headach and its clear your knowledge of this platform is great! so thanks again for giving your time to help.

An update on current progress

We've successfully authenticated two separate Battle.net accounts through Supabase.

Our current configuration is:

• Provider: custom:battlenet-oauth2
• Authorization: https://oauth.battle.net/authorize
• Token: https://oauth.battle.net/token
• UserInfo: https://oauth.battle.net/userinfo
• Scope: wow.profile
• Allow users without email: Enabled

Both accounts appear in auth.users and auth.identities, with successful sign-in timestamps. The identity data currently contains sub, email_verified, and phone_verified.

Our remaining challenge is the Supabase-to-FlutterFlow session handoff.

We're building a FlutterFlow web application using Supabase authentication.

Our current custom action manually opens the Supabase /auth/v1/authorize URL with provider=custom:battlenet-oauth2 and redirects to our published FlutterFlow application.

This successfully completes authentication on Supabase's side, but we haven't confirmed that FlutterFlow receives or persists the authenticated session.

We attempted to use the Supabase Flutter SDK's signInWithOAuth() method instead, but encountered two compilation errors:

1. OAuthProvider.custom('battlenet-oauth2') — Enums can't be instantiated.
2. OAuthProvider.custom — Member not found: 'custom'.

We've restored our original working code for now.

Could I ask for your advice on three things?

1. Is there a recommended way to complete the OAuth callback and establish the Supabase session in a FlutterFlow web application when using a custom OAuth2 provider?
2. Is this a limitation of the Supabase Flutter SDK version, or is there another supported method for specifying custom:battlenet-oauth2?
3. Once the session is established, what's the recommended way to retrieve the Blizzard provider access token so we can query the WoW character profile APIs using wow.profile?

If you have an opportunity to test this particular Flutter/Supabase integration, even a small working example would be incredibly helpful.

We're trying to establish a reliable authentication foundation before building the rest of our application.

Thanks again for taking the time to help. Your previous suggestion got us past a problem we'd been struggling with for quite some time.

[AZapata27]

Nice, glad it's working! Two accounts in auth.identities means the server side is done; what's left is all on the client.

1 & 2. The compile errors are just an older SDK. OAuthProvider used to be an enum and became a class in gotrue 2.20.0 so it could take custom providers. Any supabase_flutter from 2.14.0 on has it (current stable is 2.18.3). There's no .custom, you call the constructor:

await Supabase.instance.client.auth.signInWithOAuth(
  OAuthProvider('custom:battlenet-oauth2'),
  redirectTo: 'https://your-app.flutterflow.app/',
);

On web this opens the authorize URL in the same tab. Leave scopes out: if you pass it, it replaces the wow.profile you configured on the provider.

If FlutterFlow won't let you bump the version, your current approach (building /auth/v1/authorize?provider=custom:battlenet-oauth2&redirect_to=... by hand) works too, with two conditions:

• Same tab, not a new window or external browser. Supabase redirects back to redirect_to with the tokens in the URL fragment. When your app loads with that URL, supabase_flutter picks it up on startup, calls getSessionFromUrl and stores the session. If the redirect lands in another tab or browser, the session ends up there and your original tab never sees it.
• redirect_to must be in the Redirect URLs allow list, otherwise Supabase quietly falls back to the Site URL.

Since the hand-built URL has no code_challenge, Supabase uses the implicit flow and puts access_token in the fragment, which getSessionFromUrl accepts even if the client is set to PKCE. To confirm it worked, listen to onAuthStateChange and look for signedIn.

3. The Blizzard token comes back as session.providerToken, but only on that first sign-in. Supabase doesn't store it, and on the next token refresh the session is replaced and providerToken becomes null. So grab it right away:

Supabase.instance.client.auth.onAuthStateChange.listen((data) {
  final token = data.session?.providerToken;
  if (data.event == AuthChangeEvent.signedIn && token != null) {
    // save it: your own table (with RLS) or secure storage
  }
});

Then call the profile API with it, e.g. GET https://us.api.blizzard.com/profile/user/wow?namespace=profile-us&locale=en_US with Authorization: Bearer <token> (use your region instead of us). When the token expires, the user just signs in with Battle.net again.

Side note: your identity_data only has sub because nothing else is allowlisted. Add battletag (and id if you want it) to the provider's custom_claims_allowlist.