Authorization Code not coming back

I am implementing the API Using the Authorization Code Flow with PKCE. When I call the api directly using the /authorize api. I receive a 302, but I am receiving ’ Redirecting to /login?state’ instead of the callback url with the authorization code at the end. Are there any setup tasks that I could have overlooked?

Hi @nbaker

I think that is normal. If you do the redirect to /login… it will then immediately redirect to the callback URL.

John

I guess I should be clear where I am calling the authorize url from. Currently, I was trying to call the rest APIs directly from a native mobile app. When I stop the redirect to login I get I the /login?state. When I follow the redirect I get the HTML for the authentication prompt. I was trying to bypass the prompt and retrieve the authorization token, then make the subsequent calls to authenticate. Is there anyway to bypass the html page? Everything I have read about the Authorization Code Flow with PKCE since yesterday makes it sound like No. But, I thought I would throw my question out there anyway. Thank you in advance for your response.

It is not recommended, but you can use ROPG and embed the login within your mobile app.

I strongly recommend using the Universal Login Page (opening a full web browser from within the app), but many clients don’t want to do that and use ROPG.

You will lose the session and all the benefits you get from that if you use embedded.

John

I am just doing some initial research into what is capable with auth0 from a mobile app. We currently have a prototype using Universal Login, I was attempting to see if we could follow a similar flow calling API’s directly from the mobile app without pulling in the SDK. But the issue is with the SDK or calling the API’s I have to follow the prompt that comes back in the redirect for the use to authenticate using the universal login page then I get the authorization token back then I can request an access token. There are some native features I want to implement, so jumping out to a browser makes those harder. I thank you for your response and appreciate the feedback.

Regards,
Nick

Hi @nbaker

In spite of my never ending insistence ( :slight_smile: ) that a redirect flow is the way to go, many mobile apps are implemented using an embedded approach. This is the ROPG I discussed above, and is well supported by our mobile SDKs.

Start here: https://auth0.com/docs/best-practices/mobile-device-login-flow-best-practices

If you are invoking the calback URL, it is a redirect flow, not an embedded flow.

John

When using the ROPG flow, I have the option to include or not include the client-secret. Obviously embedding the client secret in the app is not ideal. If you do not pass the client-secret in the request, does that cause any potential issues or security threats? or does that improve the secureness of the authentication process, when using ROPG?

Yes, I understand the recommendation, and that will probably be our direction. But, I am also wondering why Auth0 does not offer a credential login with the authorization code flow that is not browser based as another option.

It just seems you just lose native capabilities with authentication, such as biometric authentication.

Hi @nbaker,

If you embed your client secret in your native app, it is no longer secret.

I am not sure what you mean by “credential login with the authorization code flow that is not browser based”. This is based on the OAuth2 standard: https://tools.ietf.org/html/rfc6749#section-1.3.1
You must have a user agent capable of being redirected. If this is not a browser, what is it?

John

Ignore that last question, if you can call it that it was not formed well. Thank you and I appreciate your timely responses.