I was trying to setup OAuth workflow using the sample application as given here
However for some reason, after I enter my okta user Id and password, I never gets the control back on my call-back URL and application just hangs indefinitely.
However the normal Javascript Singn-in widget (check this link) with the minimal authentication does work and I get the control back to the redirect URL. But this is not for an OAuth2 workflow... which is completely useless for me. Because all it does is provide authentication service using Okta tenant app and it will redirect you to your App URL. This does not provide any authorization grant workflow or other OAuth2 complex workflow. May be useful for some application but not for enterprise app where you want to retrieve user profiles, and create a login session based on user profile data retrieved from OKTA.
So my question is why is the OAuth workflow not working using the PHP application that uses JS sign-in-widget? And why there are no instructions or warning on this page for this costly service (this is not free and many org is probably paying for this)?
I spent almost a day trying to setup my Authorization server as per the instruction given on this link, but nothing works. Any idea what must be going wrong ?
Does this entire example works only after contacting OKTA support to enable the Authorization server feature? Because, I also saw a documentation here that says that this is Early Access (EA) feature (and it is probably recently added in OKTA? Extremely frustrating experience).
BTW I sent email to their customer support to enable this Authorization server feature just in case if I am missing something. If this does not work then I will have to create my own OAuth2 server using Laravel 5.4 PHP framework, which is probably the quickest solution and 100% free.
I also tried to test the Authorization server setup as per the instructions provided here.
I was successful in getting the following end point working:
/oauth2/:authorizationServerId/.well-known/openid-configuration
But I am unable to get any scope and claims using api end-point:
/api/v1/authorizationServers/:authorizationServerId/scopes
So in short, I am so far unable to test my Authorization server to get my authorization grant workflow working.
Where can I look for some troubleshooting advice?
Is there another way to check whether I have configured my OKTA Authorization server properly?
I found out that the JS script provided for the PHP sample is not right for the workflow I am working on. So after changing that JS Script, things started to work.
Edit: Also please note that Setting up Authorization server is a new feature (It is Early Access feature) in OKTA. It is not enabled by default. So you need to contact OKTA support team to enable the Authorization service endpoint and functionality provided by it.
Related
We are using Go server side code to interact with Google Ads REST API.
Namely, we authenticate it with help of "golang.org/x/oauth2" and
"golang.org/x/oauth2"packages.
In May (and recently again) we've got a email from Google regarding deprecation
Out-of-band flow, essentially rewording of this
one.
But additionally to common information, Google email listed account, which we
are using to authenticate, as being used in OOB flow and going to be blocked.
We checked our sources and available sources of mentioned packages but was not
able to find redirect URIs which are said to be used for OOB flow as one of
those:
redirect_uri=urn:ietf:wg:oauth:2.0:oob
urn:ietf:wg:oauth:2.0:oob:auto
oob
We explicitly use http://localhost in our code and long-live refresh token
(which seems never expires).
We also tried to use tcpdump to monitor our API calls, but was not able to
learn much from it, because calls are made via https and, therefore, encrypted.
We considered to use man-in-the-middle kind of proxy like
https://www.charlesproxy.com/, but haven't tried it yet, because it become
non-free and because of complexity of setup.
We tried to log our requests to API endpoint with custom RoundTripper, but
have not spotted anything suspicious. It seems that we're using refresh token
only and exchange of code to refresh token just never happen in the code.
Because of this, we don't think that further logging or monitoring with
decrypting https packages may help (but we open to suggestions how to do it better).
Finally, we decided to create a new OAuth 2 Client in the Google console with
fresh set of client id, client secret and refresh token. We obtained a new
refresh token with oauth2l and replaced
credentials in our configuration. But still, we are not sure that new account
will not be blocked by Google due OOB deprication, because seemingly it looks
the same as old one.
Questions:
Why may Google mark our account as OOB?
How can we ensure that newly created account will not be blocked?
Same here.
I find out an answer, that says "Desktop" type of Credentials uses OOB by default. Probably you need to create new Credentials with type "Web"
We have built a portal in PHP(Laravel) + Angular for a client. User Authentication is done through LDAP.
Client also has a SAS solution for Analytics and it also has LDAP Authentication (SAS Viya).
We need to redirect the user from our portal to SAS portal and the user should get logged in automatically as both portals are authenticating the users through same LDAP.
We tried a few things, but it didn't help.
I am looking for some guidance on how to implement this and if there is any programming/configuration required on our side or on SAS side.
Hard to be specific without fully understanding your use case, but you could look to handle authentication to Viya using the SASjs Adapter (disclaimer - my team built it)
https://github.com/sasjs/adapter
Just set the LoginMechanism to REDIRECTED in the config object to support SSO or alternative login flows. If you need help, my team can be contact on https://sasapps.io/contact-us, else just raise an issue on the github.
We have an implementation on Angular that may help: https://github.com/sasjs/angular-seed-app
We have integrated a VIYA Visual Analytics report into a corporate web application, using the SDK (so not realy a redirect) with single sign on.
(I don't know all the details about how we did it. my roll was in the personalization of the report, where we went further than ordinary row level security.)
I have followed the solution explained in the Azure SSO related question in the forum
After that i checked in the Portal Azure try testing from the portal itself but it keeps redirecting me to the login page only if doing it first time so its new to me though. am i missing something or i need to write login handler for my application to handle this as for now i have not created any handler for login because as per the description in the link it supposed to work .
I tried by having dd in the service provider that has been created but its not reflecting as i am confused and stuck here i am not getting where i need to write the logic where i need to handle users with type in this as for login now it is redirecting me to login route when i test it from azure portal.
Any guidance on this would be helpful !
• I would suggest you follow the Github documentation below for configuring the lavarel SAML SSO in Azure AD as it uses Lavarel package for SAML2 integration as a service provider itself. Also, as you have added the service provider in your case, it doesn’t need to if you are using v 5.5 and higher of Lavarel as it gets automatically registered. Its just for older versions that you need to add the service provider in ‘config/app.php’.
https://github.com/aacotroneo/laravel-saml2
• Thus, once you do the above and publish the config files accordingly by executing the php commands, then you will need to modify the IDP settings in PHP app’s configuration and in here, please ensure that you are entering the ACS(Reply) URL and Identifier (Entity ID) from the Azure AD created application correctly. Also, ensure that the required SAML URLs and certificate keys are correctly entered in the environment variables required in the aad_idp_settings.php
Also, please check the actual routes in the metadata, by navigating to ‘http(s)://{laravel_url}/{idpName}/metadata’ as they must be reachable for your application to pass the authentication claims to AAD for get the authentication token and since, you are configuring SSO, please check the IDP metadata for ‘http(s)://{laravel_url}/single_sign_on/mytestidp1/metadata’ and finally please ensure that ‘RedirectIfAuthenticated.php’ is configured to redirect to ‘/routesPrefix/myIdp1/login’ and the same in '/Exceptions/Handler.php'
By following the above steps, your issue should be resolved.
I work for a large company (50K+). Some orgs within the company use OKTA for auth on their servers.
I have a valid user login (via OKTA) for the servers, and can log in through a browser without any issues, but want to access this site programatically.
How can I log into these websites using my OKTA credentials?
I've found this doc: https://developer.okta.com/docs/reference/api/oidc/#authorize
that details how to use an OKTA endpoint, but it requires some info that I do not have. Namely, nonce, state, and client_id. I have no clue how to get this info.
I've found another endpoint that allows a similar login method, but only requires username and password (I forget the doc that referenced this):
https://<company>.okta.com/api/v1/authn
I am able to successfully authenticate with OKTA using this endpoint, and receive a session_token. Can I take this session_token and apply it to my arbitrary webpage somehow? I can not find any documentation that says so.
At first glance it appears that many of the API endpoints for OKTA require intimate knowledge of the hosted application (and/or are not meant to be accessed programmatically).
Is it possible to log into an arbitrary webpage that uses OKTA for authentication, with only knowledge that an end user would have (username/password/optional MFA)?
Hi not sure you found the answer yet. from your descriptions i think yours is web app, which is supposed to use authentication code flow. else, you can ask your web developers what authentication flow they use and follow the auth process accordingly.
you need to retrieve id token & access token for authentication.
Sorry if this is a bit long. Got a requirement to integrate our application with client's main portal site. The portal is maintained with a SAML 2.0 SSO features and as such, we'll need to integrate our login using SAML 2.0 as well.
The integration is done via an iframe, i.e. on the main portal, an iframe with the url pointing to our application. When user is logged in and click on a menu link, he/she will be presented with the iframe page, with our session checking with their IDP to make sure they are valid users. If so, then our application will continue to load as per usual.
The issue is that we'll need to maintain our session on our servers, while they shall maintain the session on their app server. If the user stayed on our site for a while, the session on the client main portal will timeout. And when the user click on the main portal link, they will be required to log in again.
It is suggested that when the user tries to navigate to the main portal pages, it will call a service (for now assuming it's an IDP) on our end to check whether the user session is valid or not. If it is, then we need to return a SAML response to them to validate the user.
We're exploring setting up an IDP service at our end to facilitates this, but it seems to be overkill to me. Is there a way for an IDP to only provides check on a user's session? Or is there a better option for us to achieve this?
Things that could not be changed:
1. SSO language: SAML 2.0
2. Server: Weblogic 10+
3. HTTPS a must.
Appreciate any suggestion or feedback.
Thanks.
Based on the provided information, I assume your application runs on WebLogic 10+. If the remote server too uses WebLogic you might be able to just implement the SAML authentication between the WebLogic federation. This will simplify everything and you don't need to do complicated application customization.
If the remote site does implement SAML and not on WebLogic, you still should be able to implement SAML authentication through the WebLogic configuration. This is straightforward and can be done without much hassle.
However, please be reminded that WebLogic 10+ does not support SAML SSO logout. Therefore, this needs to be handled separately.