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

jwt issuer invalid. expected: https://login.microsoftonline.com/******/v2.0 #13

Open
ardabeyazoglu opened this Issue Aug 15, 2018 · 6 comments

Comments

Projects
None yet
2 participants
@ardabeyazoglu
Contributor

ardabeyazoglu commented Aug 15, 2018

Hi,

When I tried to run nodejs-sso example, everything works fine until const {jwt} = auth.verifyJWT(req, {scp: 'access_as_user'}); throws the error jwt issuer invalid. expected: https://login.microsoftonline.com/*****/v2.0. When I checked the expected url and the issuer i placed in the code, they are exactly the same. However, when i decode jwt token i see that iss claim is different than this.

Why do i get a jwt token with a different iss claim ?

NOTE: The iss claim in the decoded token is "https://login.microsoftonline.com/a2b0309e-37c1-486d-bdbd-4d91b7d25cd5/v2.0".

@ardabeyazoglu

This comment has been minimized.

Show comment
Hide comment
@ardabeyazoglu

ardabeyazoglu Aug 15, 2018

Contributor

I think, I misunderstood something. In the example, tenant id is placed into issuer so that JWT can be verified by checking issuer (as well as audience). If i place there my office365 user's tenant id, it works okay. However, i am developing a globally available word addin, so different tenants will use the application. In this case, nobody else can verify the jwt. So, I removed issuer verification and it works for anyone now. Is this the correct thing to do ?

Contributor

ardabeyazoglu commented Aug 15, 2018

I think, I misunderstood something. In the example, tenant id is placed into issuer so that JWT can be verified by checking issuer (as well as audience). If i place there my office365 user's tenant id, it works okay. However, i am developing a globally available word addin, so different tenants will use the application. In this case, nobody else can verify the jwt. So, I removed issuer verification and it works for anyone now. Is this the correct thing to do ?

@Rick-Kirkham

This comment has been minimized.

Show comment
Hide comment
@Rick-Kirkham

Rick-Kirkham Aug 15, 2018

Contributor

@ardabeyazoglu I not sure if we support SSO for multitenant add-ins. I'll look into this.

Contributor

Rick-Kirkham commented Aug 15, 2018

@ardabeyazoglu I not sure if we support SSO for multitenant add-ins. I'll look into this.

@ardabeyazoglu

This comment has been minimized.

Show comment
Hide comment
@ardabeyazoglu

ardabeyazoglu Aug 16, 2018

Contributor

@Rick-Kirkham thanks, i realized that now. A friend with hotmail account couldnt use the addin now. If there is no support for multitenancy with sso, what is the preferred way of accessing onedrive files from addin for different tenants ? Or is it even possible ?

Contributor

ardabeyazoglu commented Aug 16, 2018

@Rick-Kirkham thanks, i realized that now. A friend with hotmail account couldnt use the addin now. If there is no support for multitenancy with sso, what is the preferred way of accessing onedrive files from addin for different tenants ? Or is it even possible ?

@Rick-Kirkham

This comment has been minimized.

Show comment
Hide comment
@Rick-Kirkham

Rick-Kirkham Aug 16, 2018

Contributor

I'm not sure that we don't support multitenant. The SSO preview program is in an uncertain state right now, so I can't give you any information yet.

This Azure sample says that you can use multitenant, but you need to replace default issuer validation with custom validation to validate against a list of safe tenants. I think this would work to get a token to Microsoft Graph (with which you can access OneDrive files). See this sample for getting access to OneDrive without using SSO: PowerPoint-Add-in-Microsoft-Graph-ASPNET-InsertChart

UPDATE: Subject to the caveat that everything connected with SSO is kind of uncertain right now, I can confirm that we do, in principle, support multitenant with SSO and the Azure sample I pointed you to is the recommended way to handle it. In particular, note in this file how default issuer validation is turned off and custom validation is added: https://github.com/Azure-Samples/active-directory-dotnet-webapp-webapi-multitenant-openidconnect/blob/master/TodoListWebApp/App_Start/Startup.Auth.cs

Also, regarding your friend with the Hotmail account, there is a bug right now in which Microsoft Account credentials may not work with SSO because the consent to the add-in is not being propagated to all the AAD servers.

Contributor

Rick-Kirkham commented Aug 16, 2018

I'm not sure that we don't support multitenant. The SSO preview program is in an uncertain state right now, so I can't give you any information yet.

This Azure sample says that you can use multitenant, but you need to replace default issuer validation with custom validation to validate against a list of safe tenants. I think this would work to get a token to Microsoft Graph (with which you can access OneDrive files). See this sample for getting access to OneDrive without using SSO: PowerPoint-Add-in-Microsoft-Graph-ASPNET-InsertChart

UPDATE: Subject to the caveat that everything connected with SSO is kind of uncertain right now, I can confirm that we do, in principle, support multitenant with SSO and the Azure sample I pointed you to is the recommended way to handle it. In particular, note in this file how default issuer validation is turned off and custom validation is added: https://github.com/Azure-Samples/active-directory-dotnet-webapp-webapi-multitenant-openidconnect/blob/master/TodoListWebApp/App_Start/Startup.Auth.cs

Also, regarding your friend with the Hotmail account, there is a bug right now in which Microsoft Account credentials may not work with SSO because the consent to the add-in is not being propagated to all the AAD servers.

@Rick-Kirkham Rick-Kirkham self-assigned this Aug 16, 2018

@ardabeyazoglu

This comment has been minimized.

Show comment
Hide comment
@ardabeyazoglu

ardabeyazoglu Aug 17, 2018

Contributor

Thanks, I ll check out azure sample.

Contributor

ardabeyazoglu commented Aug 17, 2018

Thanks, I ll check out azure sample.

@ardabeyazoglu

This comment has been minimized.

Show comment
Hide comment
@ardabeyazoglu

ardabeyazoglu Aug 17, 2018

Contributor

After digging into documentation and various tests, i found out the problem. The problem is, the example code is supposed to use Azure v2, but it actually uses v1 endpoints to download signing keys. When you sign in with a different tenant, it doesnt download the proper key and can not verify jwt. After changing discoveryUrlSegment to v2.0/.well-known/openid-configuration it works fine. In any case, issuer verification must be disabled of course.

Also, i tried with a personal consumer account (*@outlook.com) and it also worked. I ll try with hotmail as well.

I also found another problem in the example code that might be dangerous. Caching graph token to server storage is implemented as it is for a single tenant. If the app is multi tenant this means, different tenants may access to other tenants' files with the graph api, because there will always be one single graph token cached.

I modified a few lines of code for this, and sent a merge request.

Contributor

ardabeyazoglu commented Aug 17, 2018

After digging into documentation and various tests, i found out the problem. The problem is, the example code is supposed to use Azure v2, but it actually uses v1 endpoints to download signing keys. When you sign in with a different tenant, it doesnt download the proper key and can not verify jwt. After changing discoveryUrlSegment to v2.0/.well-known/openid-configuration it works fine. In any case, issuer verification must be disabled of course.

Also, i tried with a personal consumer account (*@outlook.com) and it also worked. I ll try with hotmail as well.

I also found another problem in the example code that might be dangerous. Caching graph token to server storage is implemented as it is for a single tenant. If the app is multi tenant this means, different tenants may access to other tenants' files with the graph api, because there will always be one single graph token cached.

I modified a few lines of code for this, and sent a merge request.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment