But whenever Ignition tries to make the call it seems like it is using the incorrect token for this API. Under my sessions idpAttributes property I can see the tokens that ignition received from the token endpoint and I can see the token I expect ignition to use under 'id_token':
The reason that I say ignition is using the incorrect token is that whenever I log in and look at the TRACE logs of the OIDCClientService I can see that the token it is using is the 'access_token' as seen in my idpAttributes property.
Also, in the script console, I went ahead and made a client call to that endpoint with the correct token and it returned a good response. So it isn't as if my ignition service just doesn't have permission to access this endpoint.
All of this makes me really think that the OIDC Client Service is setup to provide the wrong bearer token. At the very least the wrong one for this specific API endpoint.
Has anyone else seen a similar problem before or perhaps know a good fix for this issue? Thanks for reading all the way through this one.
I don't think the API call you linked (Microsoft's "user get" graph API) is intended as an OpenID Connect UserInfo endpoint, which is what Ignition's OIDC client is expecting. The spec is clear about using the access token from the OIDC authorization response (not the ID token) as the bearer token in the Authorization header for the UserInfo request.
How are you planning on using this extra user info that you are seeking from the user info API? Do you just want access to those attributes from a perspective session?
Apologies, I got lost there while chasing after some specific fields. Specifically, I am trying to get a user's phone number in a perspective session. The user info endpoint didn't look like it returned those values, it seemed to return the same fields that ignition already grabbed.
The /me field returns all the information that I need it seems. It makes sense that the specific /me endpoint isn't supported by the userinfo system you have. I will point out that I still have issues when I use the correct userinfo URL though. giving me a 401 unauthorized response:
I think ultimately my correct course of action would be to just make the client call in a scripting function myself and get the data I need that way. I don't think I should have any issues figuring that out.
Regarding the 401 error, you should get some additional clues in the HTTP response body, as per the OIDC spec. The Gateway's trace logger that you turned on earlier should help.
If all you are trying to fetch is the user's phone number and some additional attributes, some IdPs allow you to configure additional attribute mappings in the IdP's configuration itself (outside of Ignition). The mappings could be set on the ID token that is returned to Ignition, or on the UserInfo response...
If Microsoft does not support that, then I think you are right - best option is to fetch the phone number from the graph API you referenced using scripting from the perspective session itself, seems like you would have everything you need to make those calls (id token, access token, etc).
I can't seem to find any golden bullets online that are able to help me with that specific error. I'm assuming it means that the format of the bearer token in the header is wrong. And based on these docs, I'm assuming microsoft doesn't offer phone number as an optional claim for the id_token.
I have been experimenting with trying to make the Graph API call myself with the id_token that is returned from the IdP, but I am getting Invalid Audience responses from those calls, I'm assuming because those given tokens are meant for connections to the IdP and not to Graph.
I'm hoping I can generate a token with the proper audience by using an on-behalf-of flow, but I have yet to get it working yet. Kind of a noob with oauth stuff so learning it all on the go.
I tried adding in the graph api user.read scope into the scope field in the config but that didn't seem to change anything.
And I am kinda under the assumption that the on-behalf-of flow takes the tokens received from the authorization flow as the assertion. I might be wrong on this though, I haven't gotten it to work yet.
Yeah, I am having a ton of trouble making the graph API call with the id_token I get from Ignition. Invalid audience and all.
Not sure where to go from here, especially since I can't even get the userinfo url that I am giving in the config to give a good response. I tried specifying scope and everything. I'm not sure if the issue has to do with how Microsoft uses a different API URL for the auth and the user info endpoints.
It would be really nice to get the phone number of the user from the IdP like I'm saying, I'm just not knowledgable enough on OAuth stuff like this to really tackle it.
