Beginning in Release 2017.25, the credentials.signing.kid property of an app won't be available if the app doesn't support the key rollover feature.
An app supports key rollover if the app uses one of the following signing mode types: SAML 2.0, SAML 1.1, WS-Fed, or OpenID Connect.
Before this change takes effect, verify that your integration doesn't expect the credentials.signing.kid property
if your app doesn't have one of the listed signing mode types. This change is expected in Release 2017.25,
which is scheduled for preview orgs on June 21, 2017 and in production orgs on June 26, 2017.
Okta is changing system log data retention. System log data is available from /api/v1/events or Okta SDK EventsAPIClient.
The new data retention policy starts:
Preview and production orgs created on July 17,2017 and later will retain this log data for three months.
For the full data retention policy, see our Data Retention Policy.
You can export data before Okta deletes it. We recommend using Security Information and Event Management (SIEM) technology or Okta's API.
Using either the administrator UI or API, you can configure default scopes for an OAuth 2.0 client. If the client omits the scope parameter in an authorization request, Okta returns all default scopes in the Access Token that are permitted by the access policy rule.

For more information about setting default scopes in the API, see OAuth 2.0 API.
The wizard for creating an OpenID Connect app has been improved and consolidated onto a single screen.

Notifications are entered in the System Log via the Events API (/api/v1/events) when OpenID Connect apps are created, modified, deactivated, or deleted.
Previously these notifications appeared only in the System Log (/api/v1/logs).
Query strings are now supported in the definition of IdP Login URLs:
We are making org-wide rate limits more granular, and treating authenticated end-user interactions separately. More granular rate limits lessen the likelihood of calls to one URI impacting another. Treating authenticated end-user interactions separately lessens the chances of one user's request impacting another. We're also providing a transition period so you can see what these changes look like in your Okta system log before enforcing them:
We enforce new rate limits for all preview orgs. API calls exceeding the new rate limits return an HTTP 429 error.
As of May 8, we enabled a System Log alert which lets you know if you have exceeded any of the new API rate limits:
Warning: requests for url pattern <url-pattern> have reached
a threshold of <number> requests per <time-duration>. Please
be warned these rate limits will be enforced in the near future.
As of mid-May, we started enforcing these new rate limits for all newly created orgs. For these new orgs, instead of alerts in your System log, the API calls exceeding the new rate limits return an HTTP 429 error.
We are rolling out the enforcement of these new rate limits to all orgs this week. Once your org has the new limits, you'll see HTTP 429 errors instead of rate-limit warnings in the System Log if the new limits are exceeded.
For a full description of the new rate limits, see API Rate Limits.