https://supertokens.com/ logo
Join Discord
Powered by
NO_EMAIL_GIVEN_BY_PROVIDER issue
# support-questions-legacy
c
I'm new to setting up oauth providers and such, and am currently getting back the no email given by provider error from my Azure AD integration. Are there any common gotchas that might cause this type of error? I'm sure it's something simple in my Azure AD app registration that I'm no doing right
r
yea, it means that the user you are using to sign into doesn't have an email in their account, and supertokens requires an email
c
Ah, makes sense ok thanks. I’ve set up a new app registration in an existing tenant with Azure AD and thought the users in the tenant would be connected but sounds like I’ll have to work out how to get the users tied to my app registration. Thank you!
r
Im not sure what you mean here. I assume that you are using our thirdparty recipe?
c
Sorry, yes I’m using the third party recipe and have set up a custom signinandup feature in order to allow logging in via Azure AD
My user in Azure AD does have an email on it, but it sounds like Azure might not be returning that in the login process
I thought if it even let me log in with my credentials for my user within our Azure AD tenant that it would mean the user is also tied to my ‘app registration’ which is what you have to create in Azure AD in order to set up an oauth client
r
right yea. If you want multi tenancy AD, then that's a paid feature that's coming soon
c
Oh ok, is it possible to just use that custom third party as my only form of login though?
r
yes it is
you will just have to make sure that users have emails and that ad returns the emial
c
Ok cool. I’m hoping I just need to tie users to my app registration for that. I guess my other question should be, what makes it a multi tenant setup for supertokens?
r
if you want to have different active directory credentials configured per customer of yours, so that your customers can use their own instance of AD to login into your app
c
Ahh ok I see, so multiple AD tenants. Ok cool thanks for clarifying that for me. We just need our own AD tenant for our case. Ok I’ll try linking my AD user to my app registration and see if that resolves the no email given issue.
@rp_st Ok turns out in my backend config I was missing 'email' in the scope, and now from AD I'm getting back an access token and an id token. The id token contains email, but I'm still getting the no email given by provider error. Is there something I need to do in my backend config to tell supertokens to look at the id token for the email?
Ah I see I can add email to my access token. Just gotta see if that will be enough or if I have to explicitly decode the access token and set email in the response in backend config
Turns out I did need to explicitly decode the access token and set the email via the backend config. I’ve finally gotten a successful login!! Now I’m still getting Unauthorized responses from my api so just gotta figure out why and then my poc works.
Ok @rp_st for this roadblock I’m thinking it might be due to my integration with API Gateways and such. I’ve got one API Gateway in AWS with the backend exposing the /auth endpoints, and that’s using the same lambda function that acts as an authorizer for my different app lambda apis (exposed by another api gateway). My front end is also at a different domain as it’s a static site hosted via an S3 bucket. Does this sound like a scenario that requires the use of header based tokens rather than the cookie based tokens?
r
You should use header based auth if the apiDomain and websiteDomain don’t share a base domain
19 Views
PreviousNext
Powered by