I think this scenario :
Authentication with IDP Provider by rest api passing username, password and a saml request , Is it possibile?
I would like to have my web application which have the page with login and password, on submit we invoke IDP rest api (send username, password, saml request)
s possible to have login form in our page and "invoke" an IDP via rest api and receive saml response by IDP endpoint?
Will Single Sing on work in this way?
Thanks :-)
Image authentication Flow
Is this https://docs.axway.com/en-US/bundle/SecureTransport_55_DeveloperGuide_allOS_en_HTML5/page/Content/DevelopersGuide/restAPI/SSO_REST_API.htm my solution?
Thanks
[07/02/2023] Solved:
No Sso with The resource owner password credentials (ROPC) flow
The OAuth 2 resource owner password credentials (ROPC) grant allows an application to sign in the user by directly handling their password. In your desktop application, you can use the username/password flow to acquire a token silently.
Constraints for ROPC
The following constraints apply to the applications using the ROPC flow:
Single sign-on is unsupported.
Multi-factor authentication (MFA) is unsupported.
Check with your tenant admin before using this flow - MFA is a commonly used feature.
Conditional Access is unsupported.
Related
When a user enters their company username and password on the OKTA login page of their company dashboard so he/she can get access to apps on the OKTA dashboard as show below:
What OAuth flow/protocol is used? Is this an authentication code flow with PKCE that returns an identity token that is later sent to the OKTA dashboard backend?
Thanks
It's OIDC app, which uses authorization_code flow with PKCE. You can inspect your network tab while logging in, to find the following request https://redacted.oktapreview.com/oauth2/v1/authorize?client_id=redacted&code_challenge=GpFYQtoQXn1S1NtDJCZGTIQ8x0LSazjZJzE4KQvwPM0&code_challenge_method=S256&nonce=KLn05YhdZ87nJ4Jpbrxauo4oJQeaSV8ZLIVlBeiJT6eQSnvhuun6hvSYbE3E3dBr&redirect_uri=https%3A%2F%2Fredacted.oktapreview.com%2Fenduser%2Fcallback&response_type=code&state=If1z2jR0yCJunv0oXdzlxxAAMIoyNFsVpAuXSjZnSW5tE7vMJIL8EQEBMWqZL8xN&scope=openid%20profile%20email%20okta.users.read.self%20okta.users.manage.self%20okta.internal.enduser.read%20okta.internal.enduser.manage which clearly supports my statement
it could be either SAML or OIDC. If it is OIDC, it usually implements authorization code flow with or without PKCE.
I am using in-memory DB for storing user details in WSO2 Identity server. I create couple of users via UI and now I want to authenticate those user using some external application.
Is there any available WSO2 service which takes User credentials and authenticate based on the details provided? I saw few articles where they mainly talking about User Stores. But there, I think, they directly connect to DB to compare the credentials.
There are multiple ways to authenticate a user from Identity Server. Easiest way is that you can call the admin service (SOAP service) for authentication (RemoteUserStoreManagerService/authenticate). Or you can create a OAuth application inside the IS and use resource owner grant type to pass the credentials and authenticate.
You can find admin service related information from here [1] and password grant related information from here [2]
Is there any available WSO2 service which takes User credentials and
authenticate based on the details provided?
I believe we've misused the Token API service ( /token with password OAuth profile) to request an OAuth code and the WSO2IS effectviely validates the user's credentials.
I suggest your application would stick to some authentication and authorization standards supported by the WSO2IS, such as OAuth 2.0 or SAML.
I'm implementing Facebook and Google SSO on my website using custom workflow (redirect urls, parsing on server side etc. - no javascript) and I got to the point I have access_token, token_type and expires_in and from Google also id_token and I am confused what to do next to authenticate the user.
I read a little about authorization vs authentication, and that Facebook and Google SSO is OAuth2 which provides authorization, but not authentication, from which I understand that this way my web application is authorized to do something on behalf of the user, but I cannot be sure the user is the one who I think he is? My main source is this: OAuth Authorization vs Authentication
So, my question is, what should I do to be able to can consider the user logged in.
Thank you
In your case google (and facebook) is authenticators. This services just tells your application that user who try to login to your system is the one who he wants to appear.
Assume you differentiate users by unique email.
Your application flow should be next:
The user try to login to application using google Application do all redirection google flow stuff and gives you tokens
Application need to store this tokens for future use
Application check if this user's email presented in database
If email is presented and google returns tokens (google authenticate your user successfully) you can login user in your app
If email isn't presented in database but google authenticate user successfully you can store this user (with email) to your database - sign it up - this is new user in your system
Same flow with Facebook. Surely you can extend this logic to be more your application specific.
SSO and OAuth are different. OAuth is authorization protocol.
You are dealing Google and Facebook oauth.
OAuth
In case of oauth, after successful authentication(google/facebook) you will get access token. You can use token for maintaining the user session.
With this token user is authorized, Now you should check whether the user is present in your database, if yes then authenticate the user and redirect to your application.
SSO
SSO is user authentication service. There are way to implementing SSO like kerberos SSO, ADFS SSO.
We should never use OAuth2 access token for authentication.
For details, please refer
https://oauth.net/articles/authentication/
The OpenIDConnect, built on top of OAuth2, can be used for authentication.
Google supports OpenIDConnect
https://developers.google.com/identity/protocols/OpenIDConnect
The basic idea is Google will issue the client app (your application) a ID Token after the user has login his Google account. You can then extract user information (e.g. email, unique user id) from this ID token and proceed your login flow.
Our system architecture has this setup. We have an API that is used by a WebApp Client. We allow users to authenticate using an Identity Provider (IDP) that returns SAML.
The problem is how would you setup authentication? Which of the flow below would be more suitable?
WebApp Client controls the flow
When a user needing authentication visits WebApp Client, redirect user to IDP.
User authenticates with IDP
IDP redirect user back to webapp client with SAML response
WebApp client passes the SAML to the API.
The API will decrypt and read the attributes.
API then gives access token to the WebApp client it can use for subsequent requests.
API controls the flow
When a user needing authentication visits WebApp Client, redirect user to a special endpoint of API.
API redirects user to IDP
User authenticates with IDP
IDP redirect user back to API with SAML response
API decrypt and read the attributes
API redirects user to the WebApp client passing an access token to the WebApp client it can use for subsequent requests.
I'm currently asking myself the same questions with google idp. I thought about passing the returning code from idp to my API and then authenticating the user from my API.
If you have some return on your experience let me know :)
is there a way to ask for an OAuth authorization without redirecting the user to the service and then back again to my app?
In detail, I'm creating a web service that need access to the Facebook Graph API, that requires the OAuth 2.0 authentication. Is that possible?
Thanks
The authorization request has to happen for an authenticated (by the OAuth provider, not you) account, and for security reasons the authentication has to be a direct interaction between the end user and the OAuth provider.
Of course, the provider might decide the user is already authenticated properly (there is a fresh auth ticket in a provider-specific cookie for example) and skip the authentication sequence, but there is no way for you to force it to take your word that the user on whose behalf you are requesting the authorization indeed is an authenticated user of the OAuth provider.