The authorization code is invalid or has expired, okta_post_message, code with backslash

[Shred00]

Apologies for the httpx:// links but it seems I am not allowed to post links. Please change the httpx to https to follow the links.

I’d love nothing more than to just post this to this thread: httpx://devforum.okta.com/t/the-authorization-code-is-invalid-or-has-expired/1160/7 but there seems to bee some pretty aggressive 24h thread closing policy here.

In any case I am hitting the problem that if I get a code from the oauth2/v1/authorize/ endpoint that has a backslash in it then that code ends up failing when trying to use it with the oauth2/v1/token endpoint with:

{“error”:“invalid_grant”,“error_description”:“The authorization code is invalid or has expired.”}

The solution in a comment: httpx://devforum.okta.com/t/the-authorization-code-is-invalid-or-has-expired/1160/8?u=shred00 at the previous thread suggested simply re-hitting (i.e. pounding on) the oauth2/v1/authorize/ endpoint until I get a code without a backslash. Is that really the only way to prevent this problem?

Besides the anti-social nature of pounding APIs trying to get a useful response, it doesn’t actually work to just re-hit oauth2/v1/authorize/ as the response I get back is:

                data.error = 'login_required';
            
                data.error_description = 'The\x20client\x20specified\x20not\x20to\x20prompt,\x20but\x20the\x20user\x20is\x20not\x20logged\x20in.';

Does that mean that I need to also go back and hit v1/authn/factors/ with a new TOTP token in the case where TOTP is required?

Except that TOTP tokens cannot be reused and so now my loop to try to get a code without a backslash in it has a 30 second sleep in it to get a new TOTP token for each loop iteration – assuming that is even the solution.

Surely there has to be a better way.

What exactly is wrong with a code with a \ in it anyway? Isn’t there a way to make this kind of code usable? Is the \ some kind of escape that needs escaping itself perhaps?

Alternatively, is there some predictable and reproducible method of generating a code without a \ in it?

[krishna]

Well, there isn’t a possibility of making this predictable for okta_post_message. Ideally, the backslash character needs to be handled either by customising it entirely (use other response types) and sanitising it internally when you get it (perhaps adding an escape sequence or overriding your mechanism that takes up the backslash) Since this is a opaque token at a broader sense it is a simple string it is just a reference, hence, naturally, its format is entirely arbitrarily determined by the server that issues it.

[Shred00]

I guess what I am not understanding ultimately is why I am being given a code that simply doesn’t actually work because it has a \ in it.

[krishna]

Is the authorization code intended for your client type? The “okta_post_message” response type is custom-made for Okta applications where needed and extensiblity wasn’t considered as security was mostly the prime importance. Unfortunately, the response model for your app may not align with this. I think that is the cause.

[Shred00]

NOTE that httpx used instead of https in this post as it seems I am not allowed to include URLs in my posts

I’m not sure TBH. But ultimately I am receiving the code from the okta API by GETting httpx://foo.okta.com/oauth2/v1/authorize?’ and then POSTing that code back to the okta API at
httpx://foo.okta.com/oauth2/v1/token so it seems that the API should only issue codes that are usable by it, no?

It is okta that is generating/issue the code isn’t it?

[Shred00]

Solved this.

It turns out the \ is actually specifying an escaped/encoded value. The \ is always followed by x2D so \x2D is an escaped/encoded -. If I simply replace the \x2D in the code with - the code works!