# Using Azure AD OpenID Connect (OIDC) for Authentication
**URL:** https://discourse.sensu.io/t/using-azure-ad-openid-connect-oidc-for-authentication/1819
**Category:** Sensu Go
**Created:** [May 28, 2020, 2:01pm UTC](https://discourse.sensu.io/t/using-azure-ad-openid-connect-oidc-for-authentication/1819 "2020-05-28T14:01:37Z")
**Posts on this page:** 10
**Page:** 2
### Author:  [@jspaleta](https://discourse.sensu.io/u/jspaleta)
#### Post date: [June 15, 2020, 10:02pm UTC](https://discourse.sensu.io/t/using-azure-ad-openid-connect-oidc-for-authentication/1819/21 "2020-06-15T22:02:43Z")
@tribble3891
Maybe there’s a way to get Azure to change how its populating the groups JSON attribute via some tunable? End of the day OIDC spec seems to require whatever json attribute being used for the groups\_claim to be an array of strings, each string matching the name of a group.
What Azure is passing right now is technically an array with one very long string in it, which is definitely wrong-ish. It sure feels like Azure is breaking the spec here.
---
### Author:  [@tribble3891](https://discourse.sensu.io/u/tribble3891)
#### Post date: [June 16, 2020, 1:14pm UTC](https://discourse.sensu.io/t/using-azure-ad-openid-connect-oidc-for-authentication/1819/22 "2020-06-16T13:14:55Z")
Hey
So i removed the groups\_prefix and ran it and i see the below as the JWT:
```
{
"exp": 1592295583,
"jti": "e1425f1bdc04fcbf44623sce4ffa4d95",
"sub": "oidc:username@domain.com",
"groups": [
"[\"70aed41c-93ef-4088-9fab-196d5d978c9e\",\"8a5d117e-bbbf-4706-ac17-81136e33d7bf\",\"608d8baf-b7d4-4fe1-a5d7-aac3b133d322\"]"
],
"provider": {
"provider_id": "AzureAD",
"provider_type": "oidc",
"user_id": "6JNSeREDSv1fJODWTf0L4uMrR4s3liNuyC4lP8WW_kY"
},
"api_key": false
}
```
that then showed the following in Sensu with no permissions being granted
It definitely seems to be passing it incorrectly - i can’t see any tunables to change that, what i thought about doing was just passing a seperate attribute and using that as the group\_claim but i couldn’t get it in the right format.
All i can see in the application manifest is to set: “groupMembershipClaims”: “SecurityGroup” unfortunately but I may be missing something (its late in AU at the moment)
---
### Author:  [@tribble3891](https://discourse.sensu.io/u/tribble3891)
#### Post date: [June 16, 2020, 1:29pm UTC](https://discourse.sensu.io/t/using-azure-ad-openid-connect-oidc-for-authentication/1819/23 "2020-06-16T13:29:20Z")
Also when i try to use groups.oidc it can’t find the claim
`{"message":"GroupsClaim not found","code":0}`
---
### Author:  [@jspaleta](https://discourse.sensu.io/u/jspaleta)
#### Post date: [June 16, 2020, 6:34pm UTC](https://discourse.sensu.io/t/using-azure-ad-openid-connect-oidc-for-authentication/1819/24 "2020-06-16T18:34:57Z")
Okay I think our friends at HashiCorp have documented the magic.Specifically there is discussion about the scope called “[https://graph.microsoft.com/.default](https://graph.microsoft.com/.default)”
This maybe the missing magic that Azure requires to set the groups\_claim correctly for OIDC.
Take a look at:
> **[OIDC Provider Setup - Auth Methods | Vault by Hashicorp](https://www.vaultproject.io/docs/auth/jwt_oidc_providers#azure-active-directory-aad)**
>
> OIDC provider configuration quick starts
Azure Ref:
> **[Get access without a user - Microsoft Graph](https://docs.microsoft.com/en-us/graph/auth-v2-service#4-get-an-access-token)**
>
> Some apps call Microsoft Graph with their own identity and not on behalf of a user. In many cases, these are background services or daemons that run on a server without the presence of a signed-in user.
---
### Author:  [@jspaleta](https://discourse.sensu.io/u/jspaleta)
#### Post date: [June 17, 2020, 12:36am UTC](https://discourse.sensu.io/t/using-azure-ad-openid-connect-oidc-for-authentication/1819/25 "2020-06-17T00:36:25Z")
no the groups.oidc thing was a red herring i added to the discussion.
The groups\_claim value should be top level “groups” attribute in the JWT. We just have to find how to have Azure generated to expected array of strings as the value.
For an example of what the expected in the “groups” attribute of the decuded token take a look at this okta documentation:
[https://developer.okta.com/docs/guides/customize-tokens-returned-from-okta/add-groups-claim-org-as/#request-an-id-token-that-contains-the-groups-claim](https://developer.okta.com/docs/guides/customize-tokens-returned-from-okta/add-groups-claim-org-as/#request-an-id-token-that-contains-the-groups-claim)
The okta example shows the token request and the expected decoded JWT with a the “groups” attribute holding an array of strings.
---
### Author:  [@tribble3891](https://discourse.sensu.io/u/tribble3891)
#### Post date: [June 18, 2020, 1:32pm UTC](https://discourse.sensu.io/t/using-azure-ad-openid-connect-oidc-for-authentication/1819/26 "2020-06-18T13:32:09Z")
Yeah thats good to reference - will see if i can poke around a bit more to see if its possible to get it to return in the format is expecting without changes required in someones implementation.
Was trying to capture the oidc flow using fiddler earlier to see if i can track down where the extra pieces are coming from. Wasn’t able to find anything that allowed me to pinpoint Azure or Sensu yet (in case it was adding it on accidentally) but will keep digging.
RW
---
### Author:  [@jspaleta](https://discourse.sensu.io/u/jspaleta)
#### Post date: [June 18, 2020, 8:39pm UTC](https://discourse.sensu.io/t/using-azure-ad-openid-connect-oidc-for-authentication/1819/27 "2020-06-18T20:39:23Z")
thanks for sticking with it!
I’m not sure how much I can help without taking the plunge into Azure myself.
I’m going to try to write some basic OIDC troubleshooting instructions using curl and cmdline tools to decode the JWT so it can be inspected with jq. This sort of manual troubleshooting might help operators who are having trouble configuring OIDC service providers. I always find that if I manually do the steps involved in an API interaction, I have a better time tracking down the failures and more importantly helps me file useful bug reports.
---
### Author:  [@tribble3891](https://discourse.sensu.io/u/tribble3891)
#### Post date: [June 22, 2020, 1:16pm UTC](https://discourse.sensu.io/t/using-azure-ad-openid-connect-oidc-for-authentication/1819/28 "2020-06-22T13:16:52Z")
So having a dig around the config I still came up empty unfortunately but having a look since I am using [https://sts.windows.net/tenant\_id/](https://sts.windows.net/tenant_id/) i am using OIDC v1 tokens on AzureAD. Having a look through some of the AzureAD issues on the hashicorp/vault i was able to find in #6494 which has the comment below:
> I think we’ve finally gotten to the bottom of what’s causing this. When logging in via OIDC, the ID token is parsed, and then any claims found at the `/userinfo` endpoint are merged in. When using the `sts` endpoint the, `groups` list in the ID token is fine, but the same claim also exists in the `/userinfo` response as the stringified list: `"groups":["[\"9e58c006-42ba-4406-9b13-f6132b0b29ab\",\"352b6bbe-9f59-4a65-9a7e-2f6cd2f26494\",\"45dd570d-2706-4d0a-bea7-b09fb4ad5691\"]"]` . That value is replacing the good groups claim, which is why we’re see this issue only in the OIDC+ `//sts...` case
This seems to be similar to what I am doing and they seem to suggest moving to OIDC v2 instead which would target the following end point I believe (which is what other people seem to have tried previously):
> [https://login.microsoftonline.com/tenant\_id/v2.0](https://login.microsoftonline.com/tenant_id/v2.0)
This though when you look at the openid spec at:
> [https://login.microsoftonline.com/tenant\_id/v2.0/.well-known/openid-configuration](https://login.microsoftonline.com/tenant_id/v2.0/.well-known/openid-configuration)
This essentially gives:
`{"token_endpoint":"https://login.microsoftonline.com/tenant_id/oauth2/v2.0/token","token_endpoint_auth_methods_supported":["client_secret_post","private_key_jwt","client_secret_basic"],"jwks_uri":"https://login.microsoftonline.com/tenant_id/discovery/v2.0/keys","response_modes_supported":["query","fragment","form_post"],"subject_types_supported":["pairwise"],"id_token_signing_alg_values_supported":["RS256"],"response_types_supported":["code","id_token","code id_token","id_token token"],"scopes_supported":["openid","profile","email","offline_access"],"issuer":"https://login.microsoftonline.com/tenant_id/v2.0","request_uri_parameter_supported":false,"userinfo_endpoint":"https://graph.microsoft.com/oidc/userinfo","authorization_endpoint":"https://login.microsoftonline.com/tenant_id/oauth2/v2.0/authorize","http_logout_supported":true,"frontchannel_logout_supported":true,"end_session_endpoint":"https://login.microsoftonline.com/tenant_id/oauth2/v2.0/logout","claims_supported":["sub","iss","cloud_instance_name","cloud_instance_host_name","cloud_graph_host_name","msgraph_host","aud","exp","iat","auth_time","acr","nonce","preferred_username","name","tid","ver","at_hash","c_hash","email"],"tenant_region_scope":"OC","cloud_instance_name":"microsoftonline.com","cloud_graph_host_name":"graph.windows.net","msgraph_host":"graph.microsoft.com","rbac_url":"https://pas.windows.net"}`
the scopes\_supported don’t support the groups scope that say OKTA supports (you can pass this as a token in the azure ad app but it makes no difference). If you try and request the following scopes with v2 configured:
```
type: OIDC
api_version: authentication/v2
metadata:
created_by: admin
labels:
sensu.io/managed_by: sensuctl
name: AzureAD
spec:
additional_scopes:
- email
- profile
- groups
```
This results in the following stating:
`{"message": "GroupsClaim not found", "code": 0}`
I can’t yet see a way around this but its interesting that they were able to get groups working when using v2 (which is essentially the link you provided further up in the chain) doesn’t seem to work given the scope does not exist:
Will have a crack at the permutations again just incase i have missed something, might also have a look a bit later at the consent part of the string as maybe it never gets the access and thus never gets passed…
RW
---
### Author:  [@mattias](https://discourse.sensu.io/u/mattias)
#### Post date: [May 17, 2021, 1:36pm UTC](https://discourse.sensu.io/t/using-azure-ad-openid-connect-oidc-for-authentication/1819/29 "2021-05-17T13:36:22Z")
Hi. I found this thread by reference in [OIDC configuration (docs) needs fixing · Issue #2968 · sensu/sensu-docs · GitHub](https://github.com/sensu/sensu-docs/issues/2968) , and what you are describing above is nowhere near what I’m seeing in our Sensu 6.2.7 (official Docker images) installation.
As described over at GitHub, what I enter as `redirect_uri` on the `type: oidc` resource goes directly to the “SIGN IN WITH [provider name]” button on the login page, with only a `callback` parameter added. So only way for me to even get to Azure from that button is to set `redirect_uri: "https://login.windows.net/TENANT_ID/oauth2/authorize"`, but then `client_id`, `scope` etc URL parameters are missing (and are stripped if added to `redirect_uri`)
@tribble3891 and @seizste , what version of Sensu are you running where you are able to actually log in using Azure AD OIDC and your “only” problem is with the groups?
---
### Author:  [@seizste](https://discourse.sensu.io/u/seizste)
#### Post date: [May 17, 2021, 2:10pm UTC](https://discourse.sensu.io/t/using-azure-ad-openid-connect-oidc-for-authentication/1819/30 "2021-05-17T14:10:55Z")
Hello mattias,
we failed back to ldaps as we never got OIDC working with Azure AD.
Cheers,
Stefan
[Previous page](https://discourse.sensu.io/t/using-azure-ad-openid-connect-oidc-for-authentication/1819.md?page=1)