I would like to understand something please.
I have an application based on oAuth2 with Google Accounts.
So, teh first time I connect to this website, I am redirected to the authentication page on Google domain. So I type my email and password and I dont check "trusted computer" (or "remember me", I dont remember the exact term).
The thing is if I reboot my computer or even delete my cookie (but not my history (tested with Chrome on Android phone), I am not prompted again for the authentication and I have directly access to the application.
I would like to understand why ?
If somebody can explain it to me that should be great !
Thank you
You can actually force re-authentication in the Google OAuth api by passing &max_auth_age=0 to the auth URL.
Source:
Use the PAPE extension for further control of user authentication (optional)
Use the max_auth_age parameter in the PAPE extension to ensure that the login session of the user at Google is recent. You may also specify max_auth_age=0 to force a password reprompt.
https://developers.google.com/accounts/docs/OpenID
It's a bit confusing because they talk about OpenID, but I'm doing this successfully with Google's provided OAuth2 libs.
The Google OAuth 2 API really doesn't give you a way to force re-authentication. Lots of people have asked for this capability though, and maybe we should provide it.
It's hard to say, since it depends on what the flow was that as being executed.
Generally (with oauth) you weren't being prompted for authentication. You were being prompted for authorisation. Once you've authorised, you won't be prompted again, provided of course that the browser/google have some sort of session in existence which identifies the user.
When you say "delete my cookie", which cookie?
Yo can try going to this page https://accounts.google.com/b/0/IssuedAuthSubTokens?hl=en_GB and revoke the permission. That should then cause a repeat prompt.
Related
I need to give Google SSO a flag that force the user to reauthenticate when signing in and not to sign in automatically, I have read about the scopes/flags that could be sent with the request and didn't find relative answer, there is a flag called 'prompt' that could be set to 'consent' which ask the user to confirm they want to login but not to renter their Google password.
This option is exists in other sources that called Force Authentication but not with google.
Please confirm if there is option or not right now to make that and if not please let me know if this is something that you are working on. Thanks
I have tried searching for flags to force authentication when using Google SSO to let the user re enter their Google password
The OIDC specification has a value login for the prompt parameter. If you send prompt=login with your authorization request, then the user will be re-authenticated. However, even though Google claims to use OIDC, they seem not to support that value for the prompt parameter. The values that they support don't actually have the function you need, so I don't think it's currently possible to force that on Google auth.
I am a hardware guy first and software second so GitHub is not my forte.
I had Altium Designer setup with my GitHub server for version control. When GitHub forced 2FA recently it broke the link to Altium which, unfortunately doesn't have stellar GitHub integration.
There are 6 fields I am allowed to enter in Altium to point it to my (GitHub) server:
1.) Method (HTTP, HTTPS, file, svn)
2.) Server (URL)
3.) Port
4.) Repo Subfolder
5.) username
6.) Password
Again, nothing changed except moving to 2FA. Now, when I attempt to login it obviously says it could not connect to the server because Altium has no provisions to provide a token during the login process.
I read the article at GitHub here: https://docs.github.com/en/free-pro-team#latest/github/authenticating-to-github/using-ssh-over-the-https-port
But I have no idea if that will do anything for me. Is there a way to route my Altium server connection to use my SSH key outside of the Altium environment? Or perhaps another way to "whitelist" my desktop in GitHub for SSO?
GitHub has not forced 2FA on for users. That wouldn't be useful, because people could just not set up a second factor. It's possible your organization has required this, though.
However, GitHub is deprecating the use of a plain password when using Git over HTTPS in favor of a token. Using a plain password was already forbidden for users who use 2FA, since there's no place to send a 2FA code (and for automated systems, doing that would be very inconvenient).
In this case, it's easy to keep using HTTPS: just generate a personal access token (in the developer settings) with the repo scope and paste it into the password field. Git doesn't know the difference between a password and a token; they're both the same to it. This also has a bunch of other benefits:
If you change your password, the token isn't automatically cleaned up, so you don't have to change Altium Designer.
If you decide you want to revoke that token, you can do so independently of changing your password.
If you're using SSO, you need to enable that token for SSO using the drop-down before it can be used to access protected resources.
We are currently implementing keycloak and we are facing an issue that we are not sure what’s the best way to solve it.
We have different webapps making use of the sso and that’s working fine. The problem we have is when we make log in using the sso in one webapp and then we do the same in a different webapp.
Initially this second webapp does not know which user is coming (and it’s not necessary to be logged in to make use of it). When clicking on “login”, it automatically logs in the user (by making a redirection to keycloak and automatically logging the already logged user in the other webapp). This second logging happens “transparently” to the user, since the redirection to keycloak is very fast and it’s not noticeable. This behaviour is not very user friendly.
The question is: Taking into account that this second webapp can’t know upfront which user is accessing the site (unless actively redirecting to keycloak), is it possible to force always the users to log in for a specific keycloak client? By this I mean actually ask the visitor for user/pw even if keycloak knows already them from other keycloak clients.
Thanks in advance!
In the mail listing from keycloak, they gave me a good solution but for version 4:
in admin console, go to Authentication
make a copy of Browser flow
in this new flow, disable or delete Cookie
go to Clients -> (your client) -> Authentication Flow Overrides, change Browser Flow to your new flow, click Save."
Use logout endpoint as a default login button action in your app and redirect uri param use for login page, where you use your specific client (of course you need proper URI encoding):
https://auth-server/auth/realms/{realm-name}/protocol/openid-connect/logout?redirect_uri=https://auth-server/auth/realms/{realm-name}/protocol/openid-connect/auth?client_id=client_id&redirect_uri=.....&other_params....
=> user will be logged out and then it will be redirected to the login page
We want to integrate "AFE (Ajax File Explorer) into our Drupal application. Our users are authenticated in Drupal and it is not possible for us to ask a second time there login/pwd while opening AFE.
We received a first answer from ITHIT:
Here is how to set login and password:
ajaxFileBrowser.GetSession().SetCredentials('User1', 'pwd');
Please note that this API sets password in XHR. Setting login and
password in XHR does not provide any feedback on weather the login was
successful. That is why in general I would suggest to rely on web
browser login dialog which is displayed automatically instead of
calling SetCredentials.
However it is not clear if it is a real and robust SSO solution. We discovered that Drupal has an webdav SSO module (https://github.com/Awnage/webdavsso), we will also investigate that part. But any comment/help welcomed.
To my understanding there is no way to totally get rid of login dialog when using Basic, Digest, NTLM or Kerberos authentication with Microsoft Office.
Microsoft Office applications always ask for the authentication when used with Basic or Digest authentication. This is a Microsoft Office and Microsoft Mini-redirector limitation and there are no workaround in case your server is using Basic or Digest.
However, if you check "Remember my password" check-box it will still display the login dialog, but the user name and password will be already filled-in, so you just click "OK".
Here are some options to consider if you need to totally suppress login dialog with Microsoft Office:
Use NTLM or Kerberos authentication. In case of NTLM or Kerberos MS
Office asks for credentials only 1 time during first document access.
Implement Office Forms Based Authentication Protocol (MS-OFBA).
Implement Url-authentiation. Your urls will look like:
http://webdavserver.com/[SessionID1234567890]/path/file.docx.
In case of Url-authentiation make sure you do not include the session ID in query string, Microsoft Office will truncate it. You will have to put session ID somewhere in the path, as in the above example, which is not very convenient, when you need to mount a WebDAV folder in you file system, but still works in most cases.
Possible duplicate here Stackoverflow
I solved that problem in the same manner.
I'm using an external Node.js module, everyauth, to handle my LinkedIn API authentication. I'm not yet positive if this is a problem with the way my module handles their API, or some other API issue itself.
Basically, after a user has already granted access, LinkedIn nevertheless continues to ask whether to continue to grant access. I know this is not standard because I've seen a different user flow in other applications.
Here's an example of what happens:
You can see I granted access on Jan 11th, but this was taken on Jan 13th. Why must I re-auth!?
Do you have any idea what is causing this? I dove into the relevant LinkedIn module code for everyauth but nothing in that application flow caught my eye as the problem.
Modify the script to send them to https://www.linkedin.com/uas/oauth/authenticate instead of
https://www.linkedin.com/uas/oauth/authorize.
That will cause LinkedIn to automatically redirect them back to your site.
See more at https://developer.linkedin.com/documents/linkedins-oauth-details
If you are using the JavaScript API (which it looks like everyauth uses), then it is likely that the OAuth tokens that LinkedIn stores in the browser have become 'stale'. To ensure that the user is the correct user, the browser tokens expire after ~30 minutes.
That being said, if the session is still fresh and the authorize value is set to true, you should be able to bypass the screen you are seeing.
https://developer.linkedin.com/documents/overview