Oauth2 Authorization Code Grant: auth_code is empty in notification weekhook when client refresh token

[tuyennguyentech]

• When auth_code is empty when client refresh token, my Identity Server cannot know this new token belong to which client, may be some previous notification webhook cannot reach our identity server because of network partitions or sth.
• I think it should always have auth_code in every notification webhook or has a option to make tyk wait until notification webhook success to return new token to client

[buger]

/visor can you check?

[probelabs]

🔍 Code Analysis Results

Hello @tuyennguyentech,

Thank you for reaching out and providing details about the issue you're facing with the OAuth2 Authorization Code Grant flow. I've looked into the behavior you described, and I can clarify why auth_code is empty in the notification webhook during a token refresh.

Why auth_code is Empty

The auth_code (authorization code) is a temporary, one-time-use code that is exchanged for an access token and a refresh token. This exchange happens only during the initial authorization_code grant type flow.

When a client uses a refresh_token to obtain a new access token, the grant_type is refresh_token. In this flow, the original auth_code is not part of the request and is no longer available.

Our codebase reflects this behavior. The auth_code is intentionally populated in the notification only when the grant type is authorization_code. Here is the relevant code snippet from gateway/oauth_manager.go:

// gateway/oauth_manager.go

func (o *OAuthHandlers) HandleAccessRequest(w http.ResponseWriter, r *http.Request) {
	// ...
	authCode := ""
	if r.FormValue("grant_type") == "authorization_code" {
		authCode = r.FormValue("code")
	}
	// ...
	newNotification := NewOAuthNotification{
		AuthCode:         authCode,
		// ...
	}
	o.notifyClientOfNewOauth(newNotification)
	// ...
}

Identifying the Client on Token Refresh

While the auth_code is not available, the notification payload does include the oauth_client_id. You can use this field in your Identity Server to associate the new token with the correct client.

The NewOAuthNotification struct includes the OauthClientID field, which is populated from the token request data.

Here's the struct definition:

// gateway/oauth_manager.go

type NewOAuthNotification struct {
	AuthCode         string `json:"auth_code"`
	NewOAuthToken    string `json:"new_oauth_token"`
	NotificationData string `json:"notification_data"`
	ExpiresIn        int64  `json:"expires_in"`
	Provider         string `json:"provider"`
	APIID            string `json:"api_id"`
	OauthClientID    string `json:"oauth_client_id"`
}

And here is how it's populated during the access request handling:

// gateway/oauth_manager.go

func (o *OAuthHandlers) HandleAccessRequest(w http.ResponseWriter, r *http.Request) {
	// ...
	resp := o.Manager.HandleAccess(r)
	// ...
	oauthClientID := ""
	if resp.Output["client_id"] != nil {
		oauthClientID = resp.Output["client_id"].(string)
	}
	// ...
	newNotification := NewOAuthNotification{
		// ...
		OauthClientID:    oauthClientID,
	}
	o.notifyClientOfNewOauth(newNotification)
	// ...
}

Please check your Identity Server's webhook handler to ensure it is correctly parsing the oauth_client_id from the JSON payload. This should solve the client identification issue.

Waiting for Webhook Success

Regarding your second suggestion to have Tyk wait for the notification webhook to succeed before returning the token: this is an interesting idea for enhancing the resilience of the notification system. However, implementing this would be a significant architectural change and is best handled as a separate feature request. It would allow for a broader discussion on the implementation details, such as timeout and retry strategies.

I hope this explanation helps! Let us know if you have any other questions.

---

Powered by Visor from Probelabs

Last updated: 2025-10-02T17:06:27.339Z | Triggered by: unknown