Any updates on the ability for a user's Federation Identifier to be used as an alternative to Username for user mapping in the OAuth 2 JWT Bearer and SAML Bearer Assertion flows? @Ian Glazer
4 comments
We agree that having Federation ID as a JWT subject is a good idea and we upvoted it. Having dealt with a similar issue for our clients in the past, as a workaround/solution we implemented a Security Token Service (STS). The STS accepts a JWT (or another token format) with whatever payload that client cared to send. It then parses and validates the incoming token, looks up the user identity based on token payload, constructs and sends a new request to SF to acquire the SF access token and finally transmits the SF access token back to the caller. The STS does not have to reside on SF platform although it is certainly easier to implement if it does. The oAuth JWT Bearer and SAML bearer flows are also examples of the STS architecture, they're just operating under stricter constraints that make sense from a platform perspective. A general-purpose STS implementation in the oAuth universe happens to be a fresh out of the press standard: https://www.rfc-editor.org/rfc/rfc8693.html
