I have been integrating the google sign in via External Authentication API of ASP NETZERO. there are two parameters in that authProvider and providerAccessCode. What do I need to pass in these parameters ?
Related
DocuSign is introducing App Password authentication, a new way to authenticate via the SOAP API. Will this have any effect on existing REST APIs authentication?
Depends on what you are referring to.
Are you authenticating with the REST APIs using OAuth2?(JWT or Authorisation Code Grant flows) or are you using the old basic authentication using the X-DocuSign-Authentication header?
If it is the former, then you will be fine but if you are using the latter method, then that will be deprecated as per this
App Passwords are for the eSign SOAP API (which does not support OAuth).
App Passwords can be used with eSign REST API apps until you upgrade them to OAuth. You must plan to upgrade your eSign REST API apps to OAuth.
I am working on an existing Next.js web application, and I would like to add the DocuSign Node.JS SDK to use the JWT Auth and generate a token for my front-end application. The Next.JS app is hosted on Vercel, which can run serverless functions.
I am having trouble building the Node.JS endpoint to obtain the JWT Auth token to call the esignatures API. Does anyone know how to integrate the JWT Auth workflow into a Next.JS/React.JS application with serverless functions?
The DocuSign Node.js SDK is currently designed for server side use only.
To use the DocuSign API from the client (browser):
Only the Implicit grant flow can be used from the browser due to restrictions in the OAuth standard.
If the user of your application does not have a DocuSign account (eg the user will be a signer), then you have two options:
using JWT grant auth on a backend server, acquire an access token for a "system user" such "hr#example.com". Use this access token to create an envelope and the signing ceremony (for embedded signing). Or use the access token as needed by your app. If the app includes a (non-DocuSign) login, then you can pass the access token to the browser and make calls from it.
use the PowerForms API if it meets your needs
To make API calls from the client, you will need to build a CORS forwarding proxy since DocuSign doesn't yet support CORS natively. And to make the API calls themselves, call the API directly since no SDK is available at this time.
I am trying to implement the OAuth 2.0 in .Net core API.
I have created a simple .Net core 3.1 application that has weatherforecast controller (it is decorated with Authorize Keyword).
I haven't written anything extra as of now, nothing in a startup.cs.
Now I have published this API in the Azure App service.
Now when I hit the URL through postman, I get an 401 Unauthorized error, which is obvious as I didn't provide any token, client id, secret key to that.
Note I am using Auth type as oAuth 2.0 in postman.
So from where will I get this values:
Also, I am testing this through postman, how do I take the token in code itself validate it and run the application.
If your app has user login, you should use Authorization code flow, if you still want use Client Credentials flow, you also can refer links I provided .
For more details, please check below pic.
how do I take the token in code itself validate it and run the application.
This question, you can refer this official document.
Verify scopes in APIs called on behalf of users
Steps:
App registrations
1. Client Side
2. Server Side
Scope format like below:
Official doc: Exposed API--Application ID URI and scopes
api://{server-side-clientId}/.default
I have a Web application that currently uses OAuth2 to authenticate users using their Google accounts. The flow is quite standard: the user logs in to Google, the web app gets a callback, retrieves the user identity and stores it in the session.
Now I need to create an accompanying Chrome extension. This extension needs to access the web app underneath, so it needs to authenticate against this app. I configured my extension using the official documentation, but during experiments, I realized this is not what I need. Since it uses the OAuth2 implicit flow, it doesn't return a token that could be validated on the server side. This flow is suitable only for using Google APIs on the client side, which is not my use case. This documentation (and pretty much everything else I found on the Web) focuses on two possible cases:
We want to access Google APIs on the extension side (chrome.identity.getAuthToken()).
We want to authenticate using an alternative OAuth2 service (chrome.identity.launchWebAuthFlow()).
However, in my case, I'd like to authenticate users using Google accounts, but process the token on the server side of my Web app. I could use option 2 here, but it just doesn't "feel right" to me to create my own "non-Google authentication service" that is just a wrapper over Google authentication service, only to be able to authenticate on the server side.
Is option 2 really the only way to go, or is there any simpler way?
I also saw someone recommending using the tokeninfo endpoint to validate the token, but I find it hard to make sure that this is indeed an "official" and secure way of doing this.
To retrieve an access token that you can use on both parts of your app, the extension and the server, you should request a Google Cross-Client Access Token. This allows you to register your two apps (two client IDs) in a single project and share an access token.
This is described and discussed by Google here:
Docs: Google Identity Platform: Cross-client Identity
Video: Google Drive SDK: Cross-client authorization
The rough steps are:
You will need two clientIds, one for your extension and another for your server app
Add both clientIds to a single project
Retrieve the cross-client access token from your extension
Send it to your server via HTTPS
To do this in Chrome, it looks like you would call chrome.identity.getAuthToken() with a callback function that sends the token to your web app.
The reference says the following on chrome.identity.getAuthToken():
chrome.identity.getAuthToken(object details, function callback)
Gets an OAuth2 access token using the client ID and scopes specified in the oauth2 section of manifest.json.
and that it can take a callback function as specified as:
Called with an OAuth2 access token as specified by the manifest, or undefined if there was an error.
If you specify the callback parameter, it should be a function that looks like this:
function(string token) {...};
Ref: method-getAuthToken
Azure AD B2C with UWP sample on GitHub requires some optional steps as described on the GitHub readme which asks for us to create a web API in step 4 and hence use API scopes for that web API in the code written in app.xaml.cs
public static string[] ApiScopes = { "https://fabrikamb2c.onmicrosoft.com/demoapi/demo.read" };
Problem : I don't have a backend API for my project yet and I don't want to make a traditional web API for my project, I will be using Azure Functions for a serverless API.
But the Sign In button leads to getting authenticationToken with following method:
authResult = await App.PublicClientApp.AcquireTokenAsync(App.ApiScopes, GetUserByPolicy(App.PublicClientApp.Users, App.PolicySignUpSignIn), UIBehavior.SelectAccount, string.Empty, null, App.Authority);
As you can see above that App.ApiScopes are provided here which is a must parameter in this method, if I provide a list of string[] with an empty string only here, I am able to login but I don't see any token in the output in my UWP UI.
So how can I bypass this API scope problem and have a working sample for myself, or do I have to create a web API for some kind of security reason I mean is that a mandatory part?
You can use your app's client_id as the scope in order to get a token issued to itself.
This approach is fine if you want to tightly couple your client and API, however if you end up having multiple Azure functions, multiple clients and don't want all clients to be able to call all functions, you'll need to start splitting up their app registrations and define scopes accordingly.