We have a web application where we log users in with Google's auth2.
We also have crone jobs that are used to reply to certain emails through the gmail api.
Is the authorization for signing in and for gmail's api the same? If it is, how can we sign users out of the web app while still authorizing crone jobs?
If what you meant by signing is by using Google+ Sign-in, it says from this documentation:
Why use Google for authentication?
Providing OAuth 2.0 user authentication directly or using Google+
Sign-in reduces your development overhead. It also provides a trusted
and secure login system that's familiar to users, consistent across
devices, and removes the burden of users having to remember another
username and password.
Wherein Gmail uses the OAuth 2.0 protocol for authenticating a Google account and authorizing access to user data. This will be the same.
At a high level, all apps follow the same basic authorization pattern:
During development, register the application in the Google API Console.
When the app launches, request that the user grant access to data in their Google account.
If the user consents, your application requests and receives credentials to access the Gmail API.
Refresh the credentials (if necessary).
The difference is you will need to enable Gmail API for the credentials.
Here's the details for server-side authentication.
Related
My company (C1) has DocuSign implementation feature set up with RestApi and we use oAuth to authenticate users with email and password to create and send envelopes. This functionality works perfect.
One of our clients said they have SSO enabled in their org and would like to SSO directly to DocuSign from my company page instead of providing password option. In our current implementation, users are prompted for email address first and then the password.
If clients have SSO enabled, I assume they go directly to Docusign but to get that functionality, is there anything I need to do regarding changing the existing workflow or implementation for RestAPI.
Do we need to obtain consent for our Client (who has SSO enabled)?
Thanks in advance
You don't need to do anything differently. These clients would be able to authenticate to your integration/app using SSO. If they are already autneticated, a cookie remembers it and they would automatically be redirected back to your app. The first time, the would have to give consent to your app to enable it to do things for them, but after that - smooth sailing, without any need to login or anything.
Feel free to let me know if you run into any issues. Otherwise, you'r good.
As Inbar says, if your application uses either the OAuth Authorization Code or OAuth Implicit grant flow, then your application will automatically support SSO once the user's DocuSign account has been set for SSO.
If your application uses the OAuth JWT grant, then SSO has no bearing on your application since your application is itself authenticating with DocuSign and impersonating a user.
And the above is why Authorization Code grant or Implicit grant is preferred over JWT grant whenever there's an option to not use JWT grant.
If you're using Legacy Header authentication, your application won't be able to authenticate as users who have SSO Login enforced. Until you're able to implement one of the OAuth workflows, users who need to use your API integration will need to have their Login Policy set to allow them to login with a password. More info on Login Policy is available here: https://support.docusign.com/en/articles/How-to-exclude-specific-users-from-SSO-requirements
Within our application we provide a DocuSign integration which uses DocuSign.eSign.dll from DocuSign C# Client.
We currently use the Legacy Header Authentication to authenticate.
One of our customers, would like to enable single sign on using Azure Active Directory. They have set up their account as described on Tutorial: Azure Active Directory integration with DocuSign already (for the DocuSign App).
How do we change our integration to allow Single Sign On using SAML? What API methods do we use? Does the DocuSign C# Client support this?
Legacy Header does not support SSO Authentication. For legacy header to work, users must have a password.
You will either need to grant a Login Policy Exception (to allow them to bypass SSO) to each user that needs to authenticate via the API, or you will need to implement OAuth token authentication.
An example of OAuth token authentication in C# is available on GitHub: https://github.com/docusign/eg-03-csharp-auth-code-grant-core
Once SSO is implemented by your client and has enabled mandatory SSO in their DocuSign configuration, then you should use OAUTH either using Authorization Code Grant-User Application or JSON Web Token Grant-System Integration to generate AccessToken for your Client API user. JSON Web Token Grant is normally used when System Integration is happening in your Integration with DocuSign. In Either way, you need to ask Client API user to provide User Consent to your IntegratorKey, so that your IntegratorKey can generate AccessToken on Client API User's behalf. Obtaining Consent explains how to get User Consent for Either User Application or System Integration. In Providing the consent to your Integrator, Customers will login to DocuSign via their SSO setup, in the same way how they login to DocuSign to access DocuSign WebApp.
I'm creating a Xamarin.forms mobile app with Azure. I have enabled Authentication/Authorization in Azure to protect the APIs in Backend.
What I need is that to ask user to login with Facebook or Google and get some information of the user such as name, email and... and then save this data in a table as user information. I like to ask user just once for login and get the data and I don't need to keep the token provided by Facebook for example and refresh it always (which I red refreshing is not supported by Facebook), but also need to keep the user logged in and has access securely to Backend APIs. I am new in this and completely confused of using Azure AD, facebook and...
What is the best way to do that? I have followed this tutorial and now am able to login with Facebook.
Maybe what you are looking for is Azure AD B2C (Business to Customer), which will provide facilities to allow your customers to create an account for your app, but also login with Facebook (see here) or Google (see here).
Since Azure AD B2C implements OAuth2, integrating it in a Xamarin.Forms app by means of Xamarin.Auth should be possible (see here). Once you have acquired the OAuth2 token, you can include the token in the headers of your HTTP requests in the Authorization header with the Bearer type (see here)
Authorization: Bearer <token>
On the server side you can then validate the token. I have not used Xamarin.Auth with Json Web Tokens (JWT), but maybe you'll be able to retrieve a JWT with Xamarin.Auth, which you'll be able to validate on yourself. Otherwise, if Xamarin.Auth is restricted to access tokens, you might have to contact the authentication server to verify the token. If the token is verified successfully, you can grant the user access, otherwise, answer them with a 401.
I have 3 applications, one is desktop application and this is my client, second is my Web Api to secure and the last one is api which checks if the user with password exists.
In my case I want to connect this flow with Azure AD.
I think this should work like this:
1.DesktopApplication sending request with clientid,clientsecret, username and password to AZURE
2.Azure sending request with username and password to my api where I can check this user exist if exist I will return "true"(or somthing like this)
3. If api return "true" Azure can return to DesktopApplication token
4. DoesktopApplication will send request ot secure Web Api with token
5.DesktopApplication recive content from secure Web Api
Api in 3 point is not same api in 5 point.
Is it posible to do this flow with Azure AD or not? And if not can I do something with my flow something to secure Web Api by Azure and still store users in my old db(oracle)?
It would be better to use OpenID Connect authentication flows to authenticate the user and acquire a token that way.
The approach you are suggesting has a few downsides:
You are storing a client secret in a desktop application, which can be easily extracted by anyone.
The authentication flow that allows you to do this will not work with users who have MFA enabled / are federated users (on-prem AD/MS account/Guest account) / have expired password.
It trains users to be phished as they really should only enter their password to the actual login page.
So it would be better to use a flow like this:
Your desktop application uses Azure AD Authentication Library (ADAL) or Microsoft Authentication Library (MSAL) to authenticate the user, requesting an access token for your API
Desktop app calls API, API validates token signature, issuer, validity time etc.
It will show the user a pop-up window where they can login, and as a result you'll get an Id token (which tells your desktop app who the user is) and an access token for the API.
I'm writing a web application with a Google OAuth requirement.
Do you think I need a "traditional" login (user/password) or if I store the emails and access tokens, encrypted, is enough?
All my users has a Google Account.