We host a website which authenticates the user using OKTA. We would like to crawl the website looking for broken links.
Is there a library/way to build a general purpose link checker that can crawl websites and point out broken links that works with an OKTA login?
I have used scrapy before, but dont see anything in the documentation specific to OKTA.
We do not have recommendations for a specific web scraper that works with Okta. As far as we know, there exist no scrapers that work with SAML.
Related
Introduction
I am trying to implement cross domain authentication. The problem that I am currently facing relates to sharing the session between two domains.
Sadly, I cannot make changes to the architecture as the websites are old monoliths.
Current setup
Our current setup consists of the following:
A first web site that supports authentication. Let's call it Site1.com.
A REST API that manages the authentication.
A second website that does not support authentication. Lets call it site2.com.
Site1.com and the Authentication API reside under the same domain as shown in the diagram here above.
How the authentication works
The authentication is simple. site1.com submits credentials to auth.site1.com and on successful authentication, auth.site.com return a secure cookie.
The change
We would like to add authentication to site2.com. As the diagram below illustrates.
However, this has proven challenging as third party cookies have been disabled on Safari. Therefore the browser is not forwarding auth.site1.com cookies while the customer is on site2.com.
We ended up redirecting traffic using our gateway to overcome this problem. The gateway is presented by yellow circle in the diagram listed here below.
The current problem
Now the two websites support authentication. However, the cross domain authentication is not working. I cannot figure out how to implement this part properly. Any help will be really appreciated.
Analyzing how Google and YouTube cross domain authentication works has led me to the partial solutions listed here below. However, I cannot figure out how it performs Cross Domain SSO on the latest Safari browsers? Any indications will be really appreciated.
Partial solution 1:
Use the SameParty attribute to declare my two websites as belonging to the same party and allow cookie sharing between this.
The solution will not need traffic redirection through the gateway. However, Safari and Firefox do not support it the cookie attribute.
Partial solution 2:
I have looked into performing Silent token acquisition using an iframe. Sadly, this solution does not work with recent safari browsers according to Microsoft:
Silent token acquisition no longer works when third-party cookies are
blocked - the application embedded in the iframe must switch to using
popups to access the user's session as it can't navigate to the login
page.
Other solutions
I have read on toolkit.org's blog about the Storage Access API. However, I am not sure if this will solve my problem. Also this solution might degrade the security.
I am starting to develop a web service and I want to enable login with google using their oAuth2. However, when I started reading the requirements I see that I need to authorize my domain and use https. I am in the very initial steps and I still don't have the domain setup and no certificate yet.
Is there any way to test google integrated into my site without all this? only for development phase?
Thank you
I’d like to use the Google Cloud App Engine to serve a SPA and a REST API, both secured behind an authentication wall.
Is there any recommended way of doing this?
So far, I’ve found tutorials on how to secure an API, but not an SPA. Both ends are served from different projects, but I’d like to have a unique authentication step.
Typical flow would be:
Before serving the SPA source code, ask for authentication
Once authenticated, serve the SPA and allow the SPA to access the API resources
Thank you!
So far I’ve reviewed the documentation, it doesn't seem like there is any specific recommended way to authenticate an SPA within Google Cloud.
However, I think a pretty secure way would be to authenticate your application using the Toolkit Identity API of Google. The procedure would be to call this API from App Engine as the first necessary requirement.
This method works with Oauth2 access tokens. I think you could request for authentication credentials to your users before launching your application and granting access to the other resources/APIs.
I have a web application where user is authenticated against credentials in DB. Now a days i see the sites incuding SO that allows
users not create new credentials but use the existing credentials with sites like facebook,gmail,yahoo etc.
Can anybody brief how it is done technically so that it helps me to understand should i proceed in this direction?
I came across that it is done using OpenID but that is just protocol. If i want to allow my site to use facebook credentials, do i need to purchase
some OpenId implementing product and contact sites like facebook,gmail etc.
We made a CMS that allows users to connect to Google Analytics via a connector. I'm in the process of porting this connector to OAuth2 and am wondering what kind of application I need to register.
The issue is that the CMS is installed by our clients at arbitrary URL so we don't know the complete set of redirect URLs that I would need to register a Web Server application. Google's OAuth won't let me redirect to an arbitrary URL that I pass in during the authorization request?
Would registering an installed application and then using the urn:ietf:wg:oauth:2.0:oob special redirect URI be best? Seems like this allows the user copy/paste their authorization code from the browser back into our application.
Thanks in advance!
Indeed the installed application will allow users to copy and paste and not register. This is appropriate if the clients are end users of your application, and not say, configuring it as a plugin which will then provide web services to the client's users (where such users will then be prompted via the OAuth2 consent dialog). In the latter case you probably want to ask your clients to register their own web site as web application with Google and use a configuration tool for your CMS application to set the client's redirect URLs.
Why the distinction? Because in the first case the consent action is about your relationship with your clients, but in the latter case it expresses trust between your clients and their users. For instance, you don't want your CMS application to be disabled for abuse because one of your clients has misbehaved, as it'd affect all your clients. However, if you intermediated the consent you made it difficult for Google to understand the distinction.