2017.32

Platform Feature Enhancements

Default Custom Authorization Server

Okta provides a pre-configured Custom Authorization Server named default. This default authorization server includes a basic access policy and rule, which you can edit to control access. It allows you to specify default instead of the authServerId in requests to it:

• https://${yourOktaDomain}/api/v1/authorizationServers/default vs
• https://${yourOktaDomain}/api/v1/authorizationServers/${authServerId} for other Custom Authorization Servers

Web App Supports Client Credential Grant Type

OAuth 2.0 clients now support configuration of the web application type to use a client_credential grant type. This allows you to use one client_id for an application that needs to make user-specific calls and back-end calls for data.

OpenID Connect Group Claim Retrieves Application Groups

OpenID Connect, which uses the Okta Authorization Server, can retrieve application groups for use in tokens. Previously, application groups could only be retrieved with the Custom Authorization Server.

You can use the Okta Expression Language getFilteredGroups function to retrieve application groups.

SHA-256 Signed Certificates for New SAML 2.0 Apps

All new SAML 2.0 apps are bootstrapped with SHA-256 signed public certificates. Existing SAML 2.0 apps are unchanged.

Platform Bug Fixes

Bug fixes are expected on preview orgs starting August 9, 2017, and on production orgs starting August 14, 2017.

• The Add policy button wasn't disabled for Org Admins, who don't have permission to create authorization server policies. (OKTA-127450)
• Some requests to /oauth2/v1/authorize with the state parameter incorrectly returned an error. (OKTA-130916)
• When an ID token was minted for a custom authorization server, an app sign-on event wasn't generated. (OKTA-134554)