I'm trying to choose the appropriate authentication flow for my application. I have a portal that users create accounts/login to. When they login for the first time, I want to present them with a "Terms & Conditions" form that requires a valid signature. I want to save the signed form in our database (and link to it from our Admin panel).
I don't necessarily want users to have to create a DocuSign account to sign with. In this previous question: Embedded signers from my application shouldn’t need to login #larry-k says:
If your application makes users (who will become signers) login to the app, that is a form of authentication. You can also turn on authentication options from DocuSign. Eg include KBA (Knowledge Based Authentication) in the signing request.
Here he alludes to making my App Users into Signers, but I'm not sure how this works. I don't want to use Knowledge Based Authentication, I'm more envisioning a SSO process to create a DocuSign User based on the App User information of the user logging in.
The same article suggests PowerForm as a possible solution. What happens after the user signs the form? How can I obtain the signed copies? I gather you cannot mix/match PowerForms with API integrations? I don't want to have to require an admin to login to DocuSign to collect signed forms.
Q: What happens after the user signs the form?
A: just like any other envelope signed with Docusign, it is stored in the DocuSign cloud for the account that created the PowerForm.
A: How can I obtain the signed copies?
Q: You can download them using the eSignature REST API. You can either do this periodically (polling, not recommend) or get webhook notifications using Connect and get the signed PDF this way.
Q: I gather you cannot mix/match PowerForms with API integrations?
A: You can do that! You can have a PowerForm and you can also have separate API integration that downloads the PowerForm signed docs into your website.
Related
My use case is as follows. At regular intervals, a daemon process needs to:
Scan an email account in Office 365 for Non-Delivery Reports,
Extract some info from the email body,
Perform a task for the user account identified from that info.
My approach was to use Microsoft Graph (at which I'm new) to get in and do this - however if there is an easier approach please let me know. I'm having trouble with the .NET graph API in authenticating & getting tokens without user interaction.
I have been successful in using a Microsoft Graph console sample (https://github.com/microsoftgraph/console-csharp-connect-sample) to connect to the email account, after doing the usual setting up of the app and its permissions/scopes in Office 365, and using the App ID and "secret" to connect.
However, after spending a whole day researching and trying various ways to authenticate in the sample app, it always pops up a login window (see https://i.imgur.com/SmtPpYd.png) before API actions can be performed. Sadly I've failed to discover how to authenticate and get tokens without user interaction.
Can anyone help me in how this sample needs to be modified - i.e. how the authentication needs to be altered - in order for it to work without asking the user to log in?
I do have full admin access, so can grant whatever permissions needed in Office 365, I just need help working out what to grant and what to alter in the console app to skip the user interaction. This is my first encounter with MS Graph and my head is spinning so please be gentle. :)
Note this will eventually run as a daemon on a server, but initially I'm just trying to learn by performing actions in this console app.
This application sample is using a public client (that can't store secrets because you don't control the device/OS/environment) as you can see here.
Here the acquire a token using apps public identity and user's identity (hence the prompt).
You have to replace it by a ConfidentialClientApplication instead providing an additional secret (that you can generate from the portal) and then replace the acquisition by a client only token request.
As your application is not going to hold any user identity none of the /me shortcuts are going to work.
Lastly, as you want to crawl all users, you need to change the permissions you're requesting to an admin permission/scope and replace User.Read and Mail.Read by User.Read.All and User.Read.All. (don't forget to click on the "grant permissions button" once you save the scopes.
Hopefully that helps
I'm writing a C# application and need to scrape some information from an rss page that only offers Http Basic Authentication.
This seems to leave me with two choices
Ask the user to input their credentials into my app (which has trust issues as the app is then a potential middleman attacker?)
Get windows to insert the credentials on behalf of my app somehow (does this facility exist?)
All the examples I've seen on SO have the username/password hardcoded in the app or passed in as parameters from somewhere unspecified. My use-case is I'd like to give this app to people who may not want to trust it with their password.
How is this usually handled? Thanks
Short answer: It is not possible with basic auth. It is generally not possible with the OS a the trusted instance.
Long answer:
The proper way to solve this would involve a procedure where your application hands control to the OS (Windows), which then asks the user "Do you trust application XY to use your identity?". After user acceptance, your application would receive a security token which you could use afterwards to make your HTTP request to get the RSS feed. The problem is, that the site in question does only accept basic auth. This means, that the "security token" is the base64-encoded username and password. So the username and password would be exposed to your application anyway.
The second problem is that the OS and the RSS site have to share a secret (i.e. an encryption key not available to you or anyone else not allowed to log in site users), to enable the OS to issue a secure token that is trusted by the RSS site.
How the problem can actually be solved
The default, real-world example for the access of web resources with third-party software on behalf of the user without knowing his password is OAuth, see for example the Facebook login flow. (However, this requires the website/resource in question to provide third-party access. As your question indicates, this does not apply for your use case.)
The pattern employed is the following:
Prerequisite: You need to register your application with the RSS service provider to obtain an application ID and an application secret.
Your application redirects the user to the login endpoint of the identity provider.
The user accepts (or declines) the access of your application to his identity and data (e.g. the RSS stream).
The identity provider redirects to your app
Your application receives a token which can be used to make authenticated requests on behalf of the user. This may involve additional steps like exchanging the token for another.
Alternative Solution (does not answer your question):
Sometimes (protected) RSS feeds can be accessed via secret user-specific URLs. Of course, the user would have to provide your application with that url.
I have an API that uses another API (example google calendar API) which is authenticated with OAuth 2.
httpRequest => MyApi under test => uses external Oauth2 enabled API
If the "Oauth2 enabled API" were using HTTP basic authentication, I could just hardcode the username and password somewhere to test the application —using the username and password of a test user created in the external APP that exposes the API that I am using.
As with Oauth2 we require the user to consent (the user is usually redirected to a web page) to ask them for consent to the app to access their data through the API.
I just want to create simple Integration Test: For example, my API creates an event in the google calendar, then deletes it for cleanup, but without human intervention.
Is this possible and how?
If you're developing an API, then your tests should be against that API only. You are not responsible for the work done in the external Oauth2 API, the author of that API is. Only test your own code.
Which means, you should find a way to mock out the calls to the external API if possible.
I've been wondering about the best way to do this myself.
So far I've found a few of options:
Use the password grant type, to authenticate as a user. This is apparently no longer recommended as per best practices, but that's for end-users. Not for testing.
Use the client_credentials grant type, to authenticate as the app itself. The problem with this is that if your test depends on being able to retrieve user data, the app won't have any associated to itself, unless you manipulate it beforehand.
Request a refresh_token, to re-authenticate as a previously authenticated user. This is done by requesting the offline_access scope. A user will have to do the first authentication, get a refresh token and provision the test script with it. The script then must be able to keep updating itself with a fresh refresh token each time it runs. And if the refresh token should expire before the next run, human intervention will be required again.
Use the device_code grant type to poll for end-user consent elsewhere. This is like what YouTube uses to pair your SmartTV, whereby you start the login on your SmartTV and consent to it with a pairing code on your mobile device. Here, human intervention is required as well for the consent, at least the first time, and then again should the consent expire.
I am writing a small client to sync the outlook calendar on a machine with a user's google calendar. I am using .Net (C#).
I just read about accessing the Google Calendar API using the Google APIs Client Library for .NET and tried some basic stuff.
Now regarding the Authorization, as far as I understood, the new "OAuth 2.0" Authorization requires a "user consent", which means the user is directed to a google page where they must explicitly allow my application access to their calendar.
As if this user interaction is not enough, I as a programmer have to handle "access tokens" or "refresh tokens" and all that stuff.
Now my question is:
Is there really no easier way to have an installed application communicate with the google API to access a user's calendar?
I would like my user to enter his username/password in a "Settings" dialog. His credentials would be stored locally (encrypted of course) and then be used later on every access via google API. I know this can be dangerous and all that however I would like that decision to lie with me.
So, is that possible?
No that is not possible. The entire point of OAuth is the user never gives a 3rd party (you) their username and password. The only thing you get is a token that allows you to connect that the user can revoke at any time. (Also if the user changes his password, you can still use the same saved token and do not need to make the user update their settings).
If you decide to "work around" this by saving the username and pasword and performing the "authorization" yourself you will be in violation with the TOS of the API and will have your application banned by Google (or any OAuth provider if you try it with someone else) for not following the rules.
I've read a bit about it at http://oauth.net/ , it's "a simple way to publish and interact with protected data" apparently.
I think it's exactly what I need to provide a secure way of accessing data from an android/iphone app via a REST web service, but I can't work out exactly what it is.
So, put simply, what exactly does it do and are there any (really) simple examples of it in action I can follow, preferably implementing something in c# that can be accessed from a smartphone app?
From the link provided by Craig Stuntz:
Open ID gives you one login for multiple sites. Each time you need to log into Zooomr – a site using Open ID – you will be redirected to your Open ID site where you login, and then back to Zooomr. OAuth lets you authorise one website – the consumer – to access your data from another website – the provider. For instance, you want to authorise a printing provider – call it Moo – to grab your photos from a photo repository – call it Flickr. Moo will redirect you to Flickr which will ask you, for instance, “Moo wants to download your Flickr photos. Is that cool?”, and then back to Moo to print your photos.
DotNetOpenAuth is a good C# library for Open ID and OAuth.
OAuth is an alternative way for applications to keep login data without having the real data stored at all.
When you log into some page, you usually have a username and a personal password, or any other sort of login credentials. Now, if you want an application to be able to do stuff over that login, you would need to give that application your original login data. Which means that you enter both your username and your password into the application. That isn't bad so far, but the thing is that if you want to stay logged in via that application, it needs to store your credentials. But to make it possible to send the correct login data to the actual page, it needs to store those in their original form (just with some encryption or something). So if someone knows how the data is stored in the application, they can extract your original login credentials.
This is a security issue and exactly where OAuth comes in. With OAuth, every application is identified by a consumer key and a consumer secret. Both are unique to the client and usually no user will ever get to see those (especially not the secret). Now when you want to allow your application to have access to the page, you start the OAuth authorization process. You simply login to the page and explicitely allow that special application (identified by the consumer key) to have access. If you do that, the application will receive another key pair, the access token and access secret. That key pair only works for your account and only works when used by the exact application (identified by the consumer key, and secured to be the original app by the consumer secret). Now all the application needs to store is that access key pair (together with the already stored consumer key pair) and it will have access to the page without ever seeing your original login data.
That way, nobody will be able to get your actual login details, and nobody else (or no other application) will be able to use the generated access credentials to access the page. And if you don't want the application to have still access, you can easily revoke the access key pair, so that the application won't be able to use it any longer.
So OAuth is just a way to protect your real login data. Apart from that it does not add any other level of security or something, it's just to secure your data.