OK, I *think* I understand your use-case... Just to be clear, even after your internal discussions, you don't see a need for a client secret in this flow?
Our SAML endpoints encode the tenant in the URL like so: https://www.google.com/accounts/<tenant>/acs But I'd have no problem with supporting per tenant urls like this: https://www.google.com/accounts/acs?tenant=<tenant> In fact, our approval endpoints already support that kind of parameterization. For example, see the hd= parameter in this documentation: http://code.google.com/apis/accounts/docs/OAuth_ref.html. This is used by partners who need an OAuth token, and already have a good idea of which domain a given user belongs to. It lets us optimize the login experience. I'm a little confused by using client_id to identify something that isn't an API client. It seems like in your proposed flow you're assuming that the client_id is closely connected to the user being authenticated. That's not actually true for most of our use cases. What are your thoughts on adding an optional "tenant" parameter to both the authorization URL and the SAML ACS URL? The format of tenant would be provider specific, but I see value in using consistent parameter names. Cheers, Brian On Wed, Jul 7, 2010 at 6:25 PM, Chuck Mortimore <cmortim...@salesforce.com> wrote: > Use-case: When establishing web federation with customers we allow > them to either use their salesforce username ( enforced to be globally > unique ) or a federationid ( enforced to be unique to that particular > customer/tenant ) as the subject of their SAML assertion. Since our > SAML ACS is global for all customers, as is our OAuth token endpoint, > when federationid is being used we need an additional piece of data to > disabiguate the customer...essentially namespacing the federationid. > On our ACS endpoint, we accept a parameter. For this use-case on our > token endpoint we'll use client_id. The alternative us we use some > other proprietary parameter to identify what org the client belongs > to. > > This is optional for us, and depends on an individual customer configuration. > > We will not be issuing refresh tokens. Clients will need to get/mint > a new one-time-use saml bearer assertion if they want a new access > token > > I'm a believer that devs will have to reference other docs and specs > for the assertion flow. Perhaps making this language stronger would > help? > > -cmort > > On Wednesday, July 7, 2010, Brian Eaton <bea...@google.com> wrote: >> On Wed, Jul 7, 2010 at 4:51 PM, Chuck Mortimore >> <cmortim...@salesforce.com> wrote: >>> This thread forced a great deal on internal discussion today, and we >>> actually do have some more immediate use-cases where we'll require >>> client_id with the assertion flow >>> >>> I support leaving it as optional >> >> Can you describe the additional use cases? >> >> And do they require refresh tokens as well? >> >> I'm really worried about jamming multiple use cases into a single >> profile, and then being surprised when: >> a) that profile is suboptimal for all of the use cases >> b) developers are hugely confused by it >> >> Cheers, >> Brian >> > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
