I am trying to create a web page in PHP where people who have access to the Rotary members’ section of rotary.org can sign in using their credentials and the Sign-in redirect_URI takes them back to my web page. When I use an authorization endpoint URI of https://rotary.okta.com/oauth2/v1/authorize?response_type=code&client_id=0...&redirect_uri=http://127.0.0.1/RIBITuk/okta/?authorization-code&code_challenge=R..&code_challenge_method=S256&scope=openid+profile+email as per https://rotary.okta.com/.well-known/oauth-authorization-server I get a 400 and if I click the Go To Homepage I can log in to Rotary with my credentials and then I am taken to rotary_default - Sign In instead of returning to my web page.
I have constructed the page using the code supplied vin the okta-hosted-login sample.
I have looked at the extensive help and doc pages but cannot find out where I am going wrong.
Are you able to help me, please?
Do you see the 400 while you are still on the /authorize route in the Okta org, or after a redirect back to your application via the redirect_uri provided?
Do you see any details on the 400 error page returned back that explains what is wrong with your request?
If you’re seeing an Okta error page, double check that the client_id you provided exactly (case sensitive!) matches the one you see for the app in question in Okta and that the redirect_uri is added to the app (again, in Okta) as a Login redirect URI.
More details for the errors I’m describing found in the following docs:
Thank you for your response.
I have checked the client_d and the redirect URI and read the referenced documentation. I attach various screenshots to show the OKTA dashboard settings, the error page and the start_auth_flow code at which point the code fails.
When I use my code to login to …ISSUER=https://trial-9607388.okta.com/oauth2/default it works but when I login to …ISSUER=https://rotary.okta.com/oauth2 I get the 400 Bad Request page. There is little difference in the code in the function start_auth_flow as it is based on the code sample at https://developer.okta.com/docs/guides/sign-into-web-app-redirect/php/main/ as can see in one of the attachments.
I have also tried using the code from the the okta-hosted-login directory in the https://github.com/okta/samples-php package using a similar .env file to code at …/RIBITuk/okta
I’m sure there must be something simple which is causing my frustration.
If you’re looking to use the Org Authorization Server, make sure you set the issuer to just your Okta domain (leave off the
I couldn’t help but notice that a couple of your screenshots are from a trial org, but the one where you are getting a 400 is in a production org. Make sure you’re not mixing anything up in your config and that the Client Id you have in your code comes from the same org you are using as the issuer.
Since you’re using environment variables, there I can’t confirm that its the cause, but I have seen customers trip up on that in the past. A quick peek in our logs seems to confirm that the client_id being provided in that /authorize request does not correspond to an active OIDC application in the affected org.
I’m getting very confused! Somewhere on your extensive web pages there must be an example of what I want to do with my web page which is
- Login to OKTA to get access to the OKTA application associated with the clientID.
- Display the page at https://rotary.okta.com/login/login.htm
- Have the Rotarian login with their credentials
- After logging in return to the webpage used to login to OKTA (ie go to step 1 above).
Thank you for any enlightenment.
I have reverted to using the okta-hosted-login sample code from GitHub - okta/samples-php: samples-php and can successfully login and logout using the suggested redirect_uri of http://127.0.0.1:8080/authorization-code/callback. When I set the redirect_uri to rotary_default - Sign In I can log in to Rotary but instead of returning to http://127.0.0.1:8000 I am presented with the page at rotary_default - Sign In The authorize url (w/o client_id) is https://trial-9607388.okta.com/oauth2/default/v1/authorize?client_id=CLIENT_ID&response_type=code&response_mode=query&scope=openid+profile&redirect_uri=https%3A%2F%2Frotary.okta.com%2Flogin%2Flogin.htm&state=applicationState
Thank you for any enlightenment.
PS How do I convert from a trial account to a dev account, please?
Why are you setting the redirect_uri to your Okta org’s login page? The redirect_uri should be a route within your OIDC application that will receive the authorization code and request tokens from Okta to log the user into your application. Thats why the sample uses a route within your locally hosted application as the redirect_uri.
As far as I know, you cannot convert from a Trial org to a Dev org, but you can sign up for a new dev org here. If you need your trial extended or are looking to convert this org a paid account, I recommend reaching out to our sales team
I was under the impression that instead of implementing my own password protected web pages I could use OKTA’s code to have Rotarians sign in to rotary.okta.com and then once they have signed in I would be able to show them the protected webpages on my website. I don’t need to know their names or emails I just need to know they have valid Rotary sign in credentials.
I now presume it’s not possible to do what I want to do or is it possible and if so how?
PS I have tried the route you suggested to get a dev account but the only way I can do that is by using another work email address which I will set up if what I want to achieve is possible.
Your application shouldn’t be relying on an Okta session alone and instead should be implementing an SSO protocol like SAML or OIDC to make sure that, not only the user has a session for your Okta org, but that they are already assigned to the application within that same Okta org.
Your application would then use the SAML assertion or OIDC tokens to create a session for the user within the application and not worry about the status of the Okta session. Then your application would rely on this session to determine if the user should have access to any secure routes in your application.
If you don’t need any of their use details, within OIDC you can simply request an ID and Access Token pair with the
openid scope. This will ensure you get both types of tokens back, but no user profile data will be present within the token claims
I know I tested this at some point, but we have a very basic PHP sample app in this blog that might be worth a look: Build Simple Login in PHP | Okta Developer
I have looked at the code in ‘Build Simple Login in PHP’ and it is very similar to that in https://github.com/okta/samples-php (okta-hosted-login). I will study the SAML doc and attempt to create a web page which uses SAML as this seems to be what would fit my needs.
Thanks for your help.