DocuSign authorization code grant - multi users in Docusign Account - authentication

I'm using Authorization Code Grant to authenticate from my cloud app to DocuSign. I followed the excellent directions provided by DocuSign. When I authenticate the user I get the DocuSign Login screen and consent dialog. If I then authenticate again somehow DocuSign decides the user hasn't changed and doesn't pop up the login and consent dialog. Usually this is acceptable because it is indeed the same user.
However, if I logout of my application and then (before closing browser) relog in to my application as a different user then I am expecting that when I request to authenticate to DocuSign that the login and consent will come up. That isn't happening and DocuSign returns user information for the original user.
What mechanism is DocuSign using to determine that the user hasn't changed? Is it browser cache? More importantly is there a way I can disable that when I am starting the authorization code grant so that I can authenticate the second user?

Please add query parameter &prompt=login in your initial url. This will show login page everytime.

Related

Authenticating multiple web applications through single authentication mechanism

How can I authenticate multiple applications with a single authentication mechanism?. These applications are having existing authentication within them, perhaps I need to authenticate these apps into my system which is isolated from others. Please suggest a better approach
When using OpenID Connect, the first application the user logs in to, will redirect the user's browser to the authorization server (AS). Since the user does not have a session between the browser and the AS, it will present the login screen. The user signs in and is redirected to the application (client) with an ID token and access token. The application will then establish a session between the browser and the application (typically a cookie)
When the user navigates to the second application, it will also redirect the user to the AS, but now the user already has a valid session between the browser and the AS, so the AS won't show the login screen (it may show the consent screen if the user has not consented to the requested scopes), and will issue an ID token and access token to the second application.
Now the user has a authenticated session with both applications with a single sign on (SSO).
If you use OAuth 2.0 with OIDC, you can authenticate your user once and verify the access token at each app the user visits. This is a typical single sign-on flow (SSO).

Silent authentification with oauth2 (prompt=none)

Hi I have SPA(Single page application) where I use oauth2 implicit grant for authorization. As Identity server I have Wso2 identity server 5.4.1.
I am able to authorize the app and everything works as desired - also I configured to skip the consent.
Here goes the problem:
I am trying to silently reauthenticate logged user with following link with help of .../oauth2/authorize service and attribute prompt=none:
https://xxx:9447/oauth2/authorize?response_type=id_token token&nonce=123&prompt=none&client_id=xxxx&scope=openid&redirect_uri=http://localhost:63342/myapp/www/index.html&id_token_hint=previous_user_token
With promp=none as written here:
http://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint
I should be able to authenticate user when he is logged and the consent is configured to be skipped or always approve.
But I always get the same error back in URI:
http://localhost:63342/myapp/www/index.html#error_description=Authentication+required&error=login_required&session_state=state124124125125.1251512
This error login_required means that your user is not logged in on the IP. You must first ask him to connect by redirecting it to the authorization endpoint without the prompt parameter set to none.
See : http://openid.net/specs/openid-connect-core-1_0.html#AuthError
login_required
The Authorization Server requires End-User authentication. This error MAY be returned when the prompt parameter value in the Authentication Request is none, but the Authentication Request cannot be completed without displaying a user interface for End-User authentication.
According to the documentation, it seems that the user must choose the option on the consent page: Approve Always. Have you tested with this option?
Docs: https://docs.wso2.com/display/IS530/Basic+Client+Profile+with+Playground
Click Approve to provide consent to this action. The screen mentions
the service provider by name and requests for user consent to provide
user information to that particular service provider. The user can
either Deny to provide information to the service provider. Approve
to provide user profile information to this service provider only for
this time.
Approve Always to provide approval to share user profile
information with the service provider even in the future without
prompting for consent again.

Does Workfront API have an OAuth2 (or similar) based authentication?

I have a web application and need to authenticate users but I do not want users enter their Workfront login credentials in our webapp but want that do be done in Workfront. And after that get a confirmation (token / along with user data) from Workfront whether authentication was successful or not.
For example, user enters our webapp, presses Login button. Web app then redirects a user to Workfront where user authenticates itself and then Workfront redirects user back to our web application (or we get authentication response back via javascript library) - so at the end our web app gets back user data with a token / data or failure information.
Is that possible with Workfront API?
You can use the Workfront API to take a username/password and be returned a session ID but you can't retrieve a unique user token from it. You could always take a username/password through a custom web form and then pass it to the API and use the username + receipt of a token to validate a successful logon. That's not a perfect solution but I think that's a s close as you'll get using the existing functionality.

Single-sign-on authentication vs authorization

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.

Thinktecture Identity Server password reset redirect

In my environment I have presently two applications, lets call them portal and sso. Portal is where I manage user accounts and allow people to register. SSO is my implementation of IdentityServer. I want to require users to reset their password after 90 days or after they had their password recovered for them. I can check for this in the AuthenticateLocalAsync function, but the question is how do I redirect them to the portal password reset page? Or is it easier to add a custom page to the IdentityServer to handle password resets of this nature? Are there any examples of this, specifically where the identityserver is not embedded into the application using its login functionality?
Your best option is to create a "reset password" page in the same IdentityServer project, and issue a partial login redirecting to that page every time an user with expired password completes the sign on process successfully.
With this approach you can catch users with expired password before they are effectively logged in, without completely breaking the login flow.
You can find some details in the IdentityServer3 CustomUserService sample, specifically in the "EULA" sample which uses "EulaAtLoginUserService".
I do not think there is a way to directly redirect the user to an external endpoint (e.g. your Portal residing in another domain) during the IdentityServer login flow.