[Openid-specs-fastfed] missing oauth_token

[Matt Domsch]

Yes, helps very much, thank you.  I recalled we had switched it to a JWT format, but didn’t understand how the IDP got the access token.  Now it’s quite clear.

Matt Domsch
VP, Lead Corporate Architect
matt.domsch at sailpoint.com<mailto:matt.domsch at sailpoint.com>
mobile: 512-981-6486
www.sailpoint.com<http://www.sailpoint.com/>
[Gartner Magic Quadrant Leader 6 years running. See the report.]<https://www.sailpoint.com/identity-library/identity-governance-leader-gartner-magic-quadrant/?elqct=Website&elqchannel=EmailSig>

From: McAdams, Darin <darinm at amazon.com>
Sent: Wednesday, October 16, 2019 6:17 PM
To: Matt Domsch <matt.domsch at sailpoint.com>; openid-specs-fastfed at lists.openid.net
Subject: Re: [Openid-specs-fastfed] missing oauth_token

From prior WG discussion, those fields were replaced by the use of the public/private key pairs and JWT Authorization Grants. At IIW, one of the pieces of feedback was to add more illustrative examples of how SCIM authentication occurs; especially since the JWT flows are less widely known. I just uploaded a revision with more examples. Take a look at Section 6. In particular, 6.8 has an end-to-end example. Does that help?
https://bitbucket.org/openid/fastfed/src/master/text_spec/FastFed-1.0-Draft-01.txt


From: Openid-specs-fastfed <openid-specs-fastfed-bounces at lists.openid.net<mailto:openid-specs-fastfed-bounces at lists.openid.net>> on behalf of Openid-specs-fastfed <openid-specs-fastfed at lists.openid.net<mailto:openid-specs-fastfed at lists.openid.net>>
Reply-To: Matt Domsch <matt.domsch at sailpoint.com<mailto:matt.domsch at sailpoint.com>>
Date: Tuesday, October 15, 2019 at 1:34 PM
To: Openid-specs-fastfed <openid-specs-fastfed at lists.openid.net<mailto:openid-specs-fastfed at lists.openid.net>>
Subject: [Openid-specs-fastfed] missing oauth_token

Current draft  section 7.2.3.1. Identity Provider Sends Registration Request omits the oauth_token which is present in the “Alice” FastFed Scenario #1A with SAML + SCIM section 9.  Therefore there’s no way for the AP to authenticate any future SCIM calls to the IDP.  Was this intentionally omitted?

"oauth_token": {

       "access_token": "MTQ0NjJkZmQ5OTM2NDE1ZTZjNGZmZjI3",

    "token_type": "bearer",

    "refresh_token": "IwOGYzYTlmM2YxOTQ5MGE3YmNmMDFkNTVk",

    "expires_in": 3600

  }

Likewise, spec 7.2.3.3 Application Provider Sends Registration Response omits oauth_token which “Alice” step 11 has.  This is even more necessary, as it’s likely that the IDP (or another provider) would need it to place provisioning calls to the AP.

Alternately, oauth_token could go into spec 6.6 OAuth Access Tokens, which is a subset of 7.2.3.1 and 7.2.3.3, and which references RFC7523 where one would make use of such.  As long as it’s in here somewhere.

Thanks,
Matt

Matt Domsch
VP, Lead Corporate Architect
matt.domsch at sailpoint.com<mailto:matt.domsch at sailpoint.com>
mobile: 512-981-6486
www.sailpoint.com<http://www.sailpoint.com/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fastfed/attachments/20191018/f2da50d8/attachment-0001.html>