Given the user credentials (username+password or OAuth tokens), what are the effective ways to programmatically send and receive mail (and notifications) on behalf of that user?
I searched around and saw:
using IMAP programmatically ( Programmaticly use Gmail to receive e-mail? )
OAuth
I am intimidated by the first method and I am unsure of the capabilities the OAuth API has.
Is there some (fourth party!) service that makes it easier by offering an API?
Gmail's IMAP supports OAuth and the JavaMail API -- see here
Try Context.io a service which gives a RESTful API to email services
Related
I have a web app built on React, and backend on NestJs. I want to integrate email platforms to my app.
Let's say a user signed up in my app and then he uses other functionalities in the app.
Then he wants to receive and send emails using my app and for that, he must integrate his email account (whether Gmail, Hotmail or any other email provider) with my app.
How can I provide such functionality? and What does it call?
I have tried to research a bit on it on Google and found some options like Nylas and MailGun. But I'm not sure if they are according to my case scenario.
Any lead and suggestion is appreciated.
Thanks
You will need an IMAP client to retrieve received emails from the remote servers (of Google, Microsoft etc.) you should be able to use IMAP Simple package.
Additionally you will also need an SMTP client to send emails and for this, you would need SMTP Client.
This would require the users to disclose their SMTP/IMAP details or in some cases their actual login details which might make them uncomfortable; however this approach is universal with almost all mail service providers/servers.
Alternatively if you are just targeting Gmail you can use the Gmail API where users would grant your app the permissions to send and access their mails.
You can also use the Microsoft Graph interface to access their Mail API to both send and receive emails from Hotmail / Outlook.
Nylas absolutely fits this use case: the primary purpose is to enable developers to integrate their user's email accounts into an app. You can connect your own email account via the dashboard for testing purposes, or use the hosted auth service to automatically detect email providers and provide the appropriate login flow to connect the user email accounts. Once an account is connected, you can use the Threads and Messages endpoints to ingest email content and the Send and Outbox endpoints to send emails.
Mailgun, on the other hand, is a transactional email API service that is intended primarily for things like mass marketing emails, account management (password reset, email verification), etc. Afaik, it doesn't connect to your user's email accounts, even when it's being used to send emails from a specific user (the emails come from Mailgun's SMTP servers, not the user's provider). You can learn more about the difference between transactional email APIs (Mailgun) and contextual email APIs (Nylas) here.
I have set up Sandbox account and successfully created integrator keys for my apps REST API calls. I have docusign header (X-DocuSign-Authentication) on my code that requires username/password/integrator key for api connections. I used DocuSign ApiClient & AuthenticationApi to set it up in code. Looks good on sandbox. My question is when we go live, on production, the admin account is an individual user credential (not a generic admin account). So how can we have that set -up in every application for the REST api connections header?
For "User Applications" -- where an individual logs in and later sends envelopes -- it is vastly preferred that you use OAuth to authenticate the users. See the docs. See a recipe example of using OAuth.
If you want to use Legacy Authentication (the X-DocuSign header) for a user application, then your app needs to request (and securely store) the user's DocuSign email and password. These days, this is a not a good plan.
As you know, you must include the username and pw in each call to DocuSign if you use the Legacy Authentication scheme. The data is secure since it is within an https conversation. But requesting and storing the pw from your users is problematic.
These days, Legacy Auth should only be used for "Service Integrations" -- DocuSign integrations where there is no human involved, just an autonomous / batch process that sends out the signing requests.
I want to create a envelope on DocuSign by integrating my application.
I know about the SOBO concept but due to some limitation, can't create a generic account.
So what i am asking here "Is it possible that with, only sender username + certified integration key info, the application can make an API call to create envelopes?"
One more thing, DocuSign production SSO is enabled for all the users I want. So is there a way that I can get any help from SSO?
Any help around this is greatly appreciated.
Yes, you can use the new DocuSign OAuth support to enable your app's users to authorize your app to make API calls on their behalf.
DocuSign OAuth docs
Some notes about this:
Each of your users will need to authorize your app to make API calls on their behalf.
There are different ways to set up the OAuth capability depending on whether your app is a local/mobile app or a server-based app. The latter can protect its client secret, the former can't. Both are supported. See the docs for more info.
The new OAuth capability is not yet available for a "system account" that autonomously makes API calls on its own behalf (this doesn't apply to your question.)
Also, you say there is "some limitation" preventing you from setting up a generic (system) account to use the API on behalf of the account holders (this is the SOBO use case). I suggest that you push a little on the "limitation." Trying to get 10 or 10,000 individuals to separately authorize an app to act on their behalf is not easy. The goal of SOBO is to make it easy for authorized system apps to send on behalf of others.
I'm working on a project to connect Google Apps (Contacts, Gmail, etc.) to our own private software.
I'd like to use Hapi.js in order to achieve this, but since I have no expertise in the matter (OAuth, Google, etc) I found it to be quite challenging.
I wonder if it's posible to use Hapijs and Bell to handle the "ask permission" flow, and once authorized save the credentials to long-term uses.
Also, is it possible to use Bell to handle token refresh and consume api? (like requesting http://www.google.com/m8/feeds/contacts/default/full)
In the documentation for Bell, there's an example for twitter, basically you need to change the provider to Google: https://www.npmjs.com/package/bell
When you request access, you can add the parameter access_type with a value of offline. The server will response also with a refresh token that you can use in further requests to the API's without asking for the user credentials again.
You won't be able to store the actual user's credentials since it wouldn't be secure.
You can use the Google OAuth playground to learn more about the authentication process, here is the link https://developers.google.com/oauthplayground/
Here you can find more information and examples of using node.js and the Google API's
I'm a bit confused about how to properly and securely authenticate users using my REST API and provide and option to authenticate using other OAuth 2.0 providers as well (e.g. Facebook, Google, etc.).
Scenario
Users interact with a web application which should consume my REST API. Users should be able to login and perform CRUD operations both using username/password and by using 3rd party services such as Facebook. I will be using SSL to encrypt the traffic to the website and the API.
Without taking the 3rd party login services in consideration and by studying the various questions already asked here on SO, I thought about handling user authentication as in the picture.
Technologies and current idea
The REST API is written using JS using NodeJS and Express. The WebApp provided through another NodeJS instance is mostly AngularJS with templates which consumes the REST API.
My current idea is to let the WebApp handle the login sequence and let Facebook save their token in my DB using the callback. But this solution smells too much of workaround!
Questions
Is the authentication sequence depicted in the image correct?
How is the above authentication sequence compared to the Resource Owner Password Credential flow in OAuth2.0? Is it worth using OAuth2.0 instead of it?
How can I integrate login through 3rd parties (i.e. Facebook)? Any suggestion or (better) example?
References
passport.js RESTful auth
Login with facebook and using oauth 2.0 for authentication of REST api calls
And many others here on SO :)
My 2 cents..
The process looks good to me.. I would re-issue the token on each sign in and also keep it inside a database so tokens can be revoked easily.
Use PassportJS. Its got support for OAuth flows and supports many 3rd party integrations like FB, Twitter, Github etc..and since its a nodejs middleware.. its integration will be very tight within your application..