Okta OIDC Application Refresh Token Requests Originate From Outside the Authorized Network
Last Updated:
Overview
Okta evaluates IP addresses only during the primary authentication flow. Once a user successfully authenticates from an allowed IP address, subsequent refresh token requests bypass IP checks because the session establishes trust. Administrators observe refresh token requests originating from an unauthorized IP address in the System Log after a user disconnects from the VPN.
Applies To
- Okta Identity Engine (OIE)
- Okta Classic Engine
- OpenID Connect (OIDC)
- Authentication Policy
- System Log
Cause
The user successfully authenticates to the application from an authorized IP address. The application sends refresh token requests to Okta from the network IP address. When the user logs off the VPN, the application continues to send refresh token requests under the user's personal IP address. Okta trusts these requests because the user established a session in the browser.
Solution
Why do refresh token requests bypass IP evaluation?
Okta expects this behavior. Okta evaluates IP addresses only during the initial authentication step. Okta does not evaluate IP addresses for subsequent refresh token requests.
The Request ID is identified in the System Log.
Identify the expected behavior by inspecting the System Log for the specific event and locating the associated Request ID.
- Inspect the System Log for the following event originating from an IP address that the application authentication policy restricts:
Event Info: User Single Sign on to app
(RequestUri: /oauth2/***/v1/token
Target: OpenID Connect Client- Locate the Request ID for one of these events.
Review the following actions associated with these System Log events.
- Okta grants an OAuth 2.0 access token.
- Okta grants an OAuth 2.0 ID token.
- Okta grants an OAuth 2.0 refresh token.
- The user authenticates to the application via single sign-on.
Review the following example of a System Log event displaying the Request ID.
