#Convex Auth issuer inflexibility?

9 messages · Page 1 of 1 (latest)

jovial pecan
#

Hey,

I've tried now to connect with 2 different auth providers, one of whom had the issuer set as a single string (not allowed via convex auth) and the other had issuer set without explicitly setting the protocol ie. "theirDomain.io"

Whenever I input the issuer/domain it seems to be receptive, but fails to verify the auth as on closer inspection convex appends the "https://" itself on the cloud console.

Wondering if there is any solution to this outside of trying to find a different provider entirely.

solemn wyvernBOT
#

Thanks for posting in #1088161997662724167.
Reminder: If you have a Convex Pro account, use the Convex Dashboard to file support tickets.

    - Provide context: What are you trying to achieve, what is the end-user interaction, what are you seeing? (full error message, command output, etc.)
    - Use [search.convex.dev](https://search.convex.dev) to search Docs, Stack, and Discord all at once.
    - Additionally, you can post your questions in the Convex Community's #1228095053885476985 channel to receive a response from AI.
    - Avoid tagging staff unless specifically instructed.

    Thank you!
marble pebble
#

The issuer does need to match the domain, and the audience has to match the applicationId. What error message(s) are you seeing specifically?

jovial pecan
marble pebble
#

Are you using customJwt or oidc?

jovial pecan
#

tried both with the same result iirc

#

for now i have a cloudflare worker that "corrects" the issuer and sits as a proxy between the 3rd party auth provider and convex

#

(not ideal)

marble pebble
#

You can use an http action to do the same, but yeah not ideal. When you attempt to authenticate and it fails, there should be an error message that propagates from the convex backend through the client. I did expect customJwt wouldn’t have this issue, need to look at the source again to see if there’s a better way around it.