When using OpenID Connect with 3rd-party IdPs it might be needed to create applications in 3scale with the client ID and secret that the IdP auto-generates.

For example, Azure AD clients' secrets can include special characters, example: gkugwUSBU510*haMQV08*_:

This is currently not accepted by 3scale (when creating an application via API).

According to A.1 and A.2 of RFC 6749, the client ID and secret can be VSCHAR = %x20-7E, which is all printable characters within the range

[\x20-\x7E]

The request is to allow this range of characters both for Client ID (App ID) and Client Secret (App Key) in 3scale applications.

Things to check:

• This flow seems to be the reverse of the normal flow where those values would come from 3scale and then be communicated to idP: we'd need to check if this flow would actually work in the first place rhn-support-dmayorov or rhn-support-keprice]
  • From comment below: The flow works (tested) when the gateway is checking the validity of the token and Zync is not used to sync the applications with the IdP. This is also the flow when the IdP is not exposing any dynamic registration endpoint.
• Check if Client ID and Secret are also editable in UI, if so this behaviour should be replicated in ui, if ui only allows for auto generation, decide if we want to add feature.
  • From comment below: At the moment there is no way to edit the client id or secret in the UI but just using the APIs

Important

This estimate assumes that the only request here is that the Client ID and Client Secret can include special characters as defined in the RFC 6749. It is NOT about conforming to the RFC 6749 and is NOT about being able to edit Client ID and Client Secret from the UI.

Dev notes

The printable allowed characters are

irb(main):005:0> ("\x20".."\x7e").to_a
=> [" ", "!", "\"", "#", "$", "%", "&", "'", "(", ")", "*", "+", ",", "-", ".", "/", "0", "1", "2", "3", "4", "5", "6", "7", "8", "9", ":", ";", "<", "=", ">", "?", "@", "A", "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M", "N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z", "[", "\\", "]", "^", "_", "`", "a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m", "n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z", "{", "|", "}", "~"]

The RFC does not specify the size or maximum size of CLIENT_ID and CLIENT_SECRET. We have 255 characters in our database and we will stick to that