I am trying to implement a web application using OIDC and the Authorization Code flow. I am using the OIDC Core 1.0 specification as a reference for how things should be working. I am trying to get this working against a Microsoft ADFS 2016 server, which generally claims support for OIDC.
I have managed to get the workflow working for the most part, with one exception. When I call the token endpoint to exchange my authorization code for an access_token and an id_token, I am hoping to get the user's displayable name via the name claim. But that claim is not present in the tokens I receive from ADFS.
When I redirect to the ADFS server's authorization endpoint, I pass it scope values of openid profile. According to section 5.4 of the OIDC specification, the profile scope should cause the name claim to be requested. But I don't receive that claim. I do get a few other claims I could consider using (i.e. upn or unique_name) but I am trying to be as closely aligned with the standards as I can be.
Does this mean that ADFS 2016 is out of compliance with the OIDC specification in this particular area? Or am I mis-reading the sections of the specification that I referenced here?
The standard claims related to name are typically given_name and family_name as covered in Section 18 and I always try to code apps in terms of these values, so your concerns are correct.
As a consumer you should also be able to choose where these claims are issued. It is common for providers to not meet standards exactly though, so you may have to adapt your code slightly.
Here is an MS Article on customizing ADFS claims, though it may not give you a clear sense of how claims should work.
FURTHER INFO
At a high level, here is how OAuth systems are meant to issue claims:
For further info see this article on Personally Identifiable Information (PII) - and see how Claims Mappers work in the Curity system.
It may be that your ADFS provider doesn't give you full control, but it is worth being aware of the design patterns, and to reduce user info in tokens where you can.