SCR007 OAuth2 Application detail

Screen displays form for editing OAuth2 Application fields

Fields:

• Name - required localizable string
• Icon - optional image
• URL to the Application's home page - optional URL, support only http:// and https:// protocols
• Description - required localizable string, a concise description of the Application
• Privacy Policy URL - optional URL, support only http:// and https:// protocols
• A list of redirect URI's:
  1. May contain query string parameters
  2. Must not contain anything in the fragment.
     • The registration server should reject the request if the developer tries to register a redirect URL that contains a fragment.
  3. For native and mobile apps, the platform may allow a developer to register a URL scheme such as myapp:// which can then be used in the redirect URL. This means the authorization server should allow arbitrary URL schemes to be registered in order to support registering redirect URLs for native apps.
  4. Any unsafe characters must be URL-encoded
  5. Portal must not register unsafe known URLs like javascript:, data:, ftp:, file:, etc.
• Client type - localized, single select - one of:
  • Confidential  - web server remote client, is able to keep client_secret safe
  • Public - mobile app or JS/SPA application remote client, cannot keep client_secret safe
• Allowed Authorization Grants - localized, multiple select (checkboxes) 
  • Authorization Code 
    • For web server remote client,
    • User approves the client using
      SCR001 User authorizes application (OAUTH2-57) portal screen
    • Available only for Client type = Confidental
    • Available after OAUTH2-11 implementation
  • Implicit
    • For native mobile application or JS / SPA client
    • User approves the client using
      SCR001 User authorizes application (OAUTH2-57) portal screen
    • Available only for Client type = Public
    • Available after OAUTH2-12 implementation - probably won't be ever available due to security considerations
  • Resource Owner Password Credentials
    • For trusted mobile app or trusted web server remote clients,
    • User stores login and password inside the remote client that sends login+password to directly obtain token, no user approval on portal side
    • Available for Client type = Confidential, Public
    • Available after OAUTH2-13 implementation
  • Client Credentials
    • For web server remote client
    • No user authorization, client acts in portal on behalf of OAuth2 Application owner /  creator
    • Available only for Client type = Confidential
    • Available after OAUTH2-14 implementation
  • PKCE extended Authorization Code
    • For JS/SPA applications + native mobile apps following [RFC 8252] OAuth 2.0 for Native Apps
    • User approves the client using
      SCR001 User authorizes application (OAUTH2-57) portal screen
    • Available for Client type = Public
    • Available after OAUTH2-26 implementation
• Client Id - unique string
  • pre-generated for new Application
  • can be changed using a text field for new Application
  • cannot be edited/changed for existing application
• Client Secret - password string
  • visible only for Confidential client types 
  • pre-generated and visible for a new Application
  • cannot be edited / changed
  • for existing application can be reset via REQ011.UC005 Reset OAuth2 Application client secret (OAUTH2-78)

Screen may contain a list of OAuth2 scopes the application is allowed to request (see  OAUTH2-81 REQ011.UC008 OAuth2 Admin assigns scopes to OAuth2 Application)

UX considerations:

• UI should consider which piece of information will be displayed to the App User (end user), or which, are for internal use only
• UI should consider asking what type of application it is (eg: web server, browser-based/SPA, native/mobile app), whether it is public/private, and from that choice, potentially restrict options for grant types application can use
• Based on OAUTH2-90 and OAUTH2-91 UI may show QR with clientId or email link/button