Adopt to sap_id_type to solve principle resolution

[strehle]

Describe the Problem

Detail of former issue is in #1041 (comment)

New for SCI is now a sap_id_type claim. This claim is always in the JWT (id and access token).
With value app you can rely on a client authentication only and the sub is then always the client_id.

With value user you can rely on a User authentication and then you can rely that sub is the user identifier. This Identifier is called Subject Name Identifier in SCI and in the Admin UI customers can define this. Typically the userId, or email or user_uuid.

Propose a Solution

Sub claim is always in a token so you can now rely on sap_id_type=user + sub (value)

Describe Alternatives

No response

Affected Development Phase

Getting Started

Impact

No Impact

Timeline

No response

[strehle]

@MatKuhr FYI

[newtork]

you can now rely on sap_id_type=user + sub (value)

Is there a documentation somewhere referencing and explaining this new(?) claim?

[strehle]

you can now rely on sap_id_type=user + sub (value)

Is there a documentation somewhere referencing and explaining this new(?) claim?

Maybe less what you expect, but it is mention on this protected list, because you cannot set the claim/value on your own:
https://help.sap.com/docs/cloud-identity-services/cloud-identity-services/configure-default-attributes-sent-to-application

and we added it to the public OIDC metadata, e.g. https://accounts.sap.com/.well-known/openid-configuration
or https://[tenant].accounts.ondemand.com/.well-known/openid-configuration
-> claims_supported list.

The value is "app" and/or "user". You should rely on "user"