I am using oAuth authentication for the first time and finding some challenges in implementing a working code.
I tried using ajax calls but failed.
The idea is - my java service is enabled with oAuth2.0 and I have my callback URL, my Auth URL, my token URL and also the client id and client secret, but how do I put it all together to get a workable code?
Any samples would help -
Either AJAX call (jQuery) to put in my UI5 application or even better with JSONModel.loadData().
Related
I am working on migrating Docusign basic Authentication to OAuth2.0. I followed the article How to get access token with JWT grant authentication.
However, I am confused when trying to get the eSignature working.
Our current flow is:
We don't use a phyiscal document file, instead we use a template (templateId) that we uploaded to docusign ahead of time. Then when we make an API call, docusign returns an external url that we use to direct the user to sign the form. After the user signs the form, Docusign uses the return url that we provided to direct the user back to our application.
Any ideas which method that I should use to achieve it? With Docusign Oauth2.0 migration, we only need to update the authentication piece, we do not need to make different API calls. In other words, We can continue to use restapi/v2 with OAuth2.0 authentication, everything else will work as before. right?
However, I noticed that the legacy login URL still requires api_password
https://www.docusign.net/restapi/v2/login_information?include_account_id_guid=true&api_password=true&login_settings=all
If we do have to call restapi/v2.1 Docusign REST API along with OAuth2.0, in this article How to request a signature using a composite template. At the end, the article shows that its expected response URL.
"url": "https://demo.docusign.net/Signing/MTRedeem/v1/09f2e35e-xxxx-xxxx-xxxx-1fbc6fcf77ed?slt=eyJ0eX...i3x-4g"
Any inputs would be really appreciated! Thank you!
You can still use the same URL from the eSignature REST API v2.0 to make all API calls to DocuSign, except the login_information call in your post.
The rest of your scenario - using a template, redirecting the user etc. - can be done just the same with your access token obtained using OAuth 2.0
To get the user's information with OAuth you use the getUserInfo() call and you can read all about it on the developer center.
(the URL is https://account.docusign.com/oauth/userinfo)
The API I'm using requires that my OAuth 2.0 redirect URI be urn:ietf:wg:oauth:2.0:oob. So when I initiate the authentication flow in Paw, I am presented with this:
Where do I paste that code into Paw? Or is there a more automatic way I should be authenticating?
It seems like you're using an OAuth 2 "Authorization Code" flow, in which case the code needs to be then sent back to the server in order to get an authentication token.
Unfortunately, as your API doesn't provide the code automatically through a URL query param, Paw isn't able to retrieve the code and continue the normal flow. I'm afraid that in your case you won't be able to use Paw's automated OAuth 2 flow.
Instead, you may setup manually multiple requests in Paw:
One request to query this page (the Authorization URL)
One request to get access token using the code you've got (the Access Token URL)
My API uses the devise_token_auth (omniauth) gem for authentication in the Rails 5 backend. The frontend are using ng-token-auth (Angular 1.x).
I have all the API requests in Postman. I did the security implementation and I need authenticate Postman with every request. Devise_token_auth uses authentication with OAuth 2 and I am having difficulty to implementing this authentication.
For this type of authentication, using Postman, what is the process needed to obtain the connection?
For getting the token, there are few things you need to setup.
The client ID, client Secret are the things to be added into your identity serve as clients.
The Auth Url and access token url will be provided by the identity server and you will be able to get the url by hitting the identity server website when its ready for testing.
The grant type also is dependent upon how you setup the client. For the first time try doing the access token instead of authorization code flow.
For the authorization code flow its a two step process. Get the code first and use the code to get the token.
I recomment watching this tutorial which will help you in understanding Identity server and oauth better.
https://app.pluralsight.com/library/courses/oauth2-openid-connect-angular-aspdotnet/table-of-contents
I apologies in advance for incorrect use of oauth terms.
I have 4 "parties" as follows (intentionally not using oauth terms where possible):
End-user in a browser (javascript)
Our website (aspnet)
Our web api (aspnet)
Our auth server (aspnet utilising identityserver 4)
My usage scenario is that we only want the API to be called by a browser that has requested a page from the website first. Whilst the API doesn't release sensitive information, we would like to introduce a layer of complexity with regards to the API being spammed.
Our end user's will not be logged in.
I imagine such a flow being akin:
Browser requests a certain page from the website (one that will likely lead to js making an api call)
Website requests token from auth server
Auth server verifies token request came from website (the server itself)
Auth server returns a token to the website
Website returns page including the access token
Browser is able to make a request to api using token
Although convoluted, I believe this is at least similar to the Client Access Grant flow?
These tokens could then be throttled either by website or auth server.
Yes, I'm aware that this doesn't protect the api from numerous other vectors, but it does eliminate the simplest of cases which is all we're looking to achieve for now. I'll add, I didn't define this requirement, I'm simply trying to find a way to achieve it utilising techs out there instead of making the mistake of rolling anything of my own.
Could someone confirm/deny that there is an oauth flow I could use here? Any sample projects using the given flow and IdentityServer?
IdentityServer3 / non-aspnet[core/5] examples are fine, I can translate.
What you describe is the Client Credentials Grant where your website (client) gets an access token from identityserver (auth server). That access token can then be used to call endpoints on your web API (resource server).
The token is a bearer token and can be used by anyone who has it, so if you are comfortable with your website passing it back to a browser on an HTTP response, then it will work just fine.
I'm not sure what you mean by throttling the tokens - once minted they are valid for their lifetime. I guess you can keep the time-to-live very short to achieve the single usage you want though.
You can implement the "Authorization Code Flow" in this situation?
A single page app in www.app.com
A REST backend in www.backend.com
Is possible to obtain via javascript an "authorization code" and then pass it to the "backend" for this get the "access token"?
In theory, using the authorization code flow (or the hybrid flow) with a JS/mobile/desktop application is definitely possible, and you don't even need to store client credentials for that (you could, of course, but extracting them is so easy that it would be pointless).
Contrary to popular belief, client authentication is not required for "public" applications (i.e apps that cannot safely store their credentials, which includes JS apps) when using the authorization code flow:
If the client type is confidential or the client was issued client
credentials (or assigned other authentication requirements), the
client MUST authenticate with the authorization server as described
in Section 3.2.1.
https://www.rfc-editor.org/rfc/rfc6749#section-4.1.3
f the Client is a Confidential Client, then it MUST authenticate to the Token Endpoint using the authentication method registered for its client_id, as described in Section 9.
http://openid.net/specs/openid-connect-core-1_0.html#TokenRequest
In practice, I'm pretty sure most authorization/authentication servers will enforce client authentication when using the authorization code flow and will instead recommend using the implicit flow for public apps.
If your authorization server supports this scenario, using the authorization code flow in your JS app should be easy if you use response_mode=query (or better: response_mode=fragment as suggested by #Hans), since you can use your JS main page as the redirect_uri and use some JS to extract the authorization code from the query string or from the fragment.
That is possible by setting the redirect_uri to somewhere in your SPA, pickup the code from the authorization response (using any of the methods described in How to get the value from the GET parameters?) and pass it on to the backend in an application specific way. When using OpenID Connect there's the option to have the code delivered in the fragment of the redirect_uri which has some security advantages over having it delivered as a query parameter.