RFC 7522 -- using SAML credentials for OAuth2 grants

Questions
1

We have a customer that authorizes third-party users access to certain REST API services in their system. These are currently secured with OAuth 2 password grant, so the third parties pass in their personal username and password and the shared client ID and client secret and get an access token in return. They use this token to get access to the services. The customer doesn’t want to distribute client ID and client secret anymore, so they would like to authorize access solely based on user name and password. RFC 7522 seems to say this is possible. Does Okta implement this RFC, or anything similar?

2

Hi @gregcharles

RFC 7522 feature is not currently implemented in Okta. The best solution to achieve this use-case would be by using Resource Owner Password Flow.

3

Thanks @dragos for the reply! However, your link to Resource Flow says:

Important: The call to the /token endpoint requires authentication. In this case, it is a Basic Auth digest of the Client ID and Secret. You can find the client ID and secret in your application’s General tab. For more on Basic Auth, see Client Authentication Methods.

Based on that, the only difference to what I’m doing now would be the client ID and secret would be encoded into an authorization header instead of being put into the request body. The requester would still need to have the client secret, right?

4

Hi @gregcharles

Yes, it requires a client ID and client secret. In order to protect this credentials, you can use an API gateway which will forward the request to Okta and append the client ID and client secret inside the authorization header.

5

Thanks again! Yes, a gateway seems possible, but I’d prefer the user to only send username/password credentials directly to Okta. I’m just wondering if it’s possible to implement an implicit flow or PKCE where the client isn’t a web browser. All the scenarios I can see on Okta and other sites assume the client is using a browser, but don’t specifically say that’s required. Are there any case studies anywhere with a non-browser client?

6

ROPF will become deprecated: https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-3.4

7

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.