I want to execute the signup user-flow in Azureb2c from an ASP.NET Core Web API instead of executing it from our frontend app. To achieve this I found an approach of using API connector.
The documentation of API-Connector says
You can use API connectors to integrate your sign-up user flows with REST APIs to customize the sign-up experience and integrate with external systems
I assume with this explanation that I can execute a user-flow defined in AzureB2C for signin-signup from a Web API as a Http Request. What that is not clear is how the API connector actually work. When we still are in development phase and want to execute the API-Connector (and execute the user-flow via this), what type of http request we are supposed to send? Will it contain the Id/password we had defined when creating the API-Connector along with the user-details that needs to be passed to signup user-flow? What the URL which we had added when creating the API-Connector will be used for?
Unfortunately there is not much data available on API-Connector apart from the Azure official documentation, which I felt a bit confusing.
Related
I am creating a React SPA that will connect to a dotnet Web API backend. I want to use b2c to handle auth.
I want to have endpoints in the API protected based off the claims in the b2c token, also want to check claims in the frontend aswell.
Following along with token enrichment docs - https://learn.microsoft.com/en-us/azure/active-directory-b2c/add-api-connector-token-enrichment?pivots=b2c-user-flow
I can use an API connector to enrich the token with additional claims before it is sent back to the client, presumably with a function to provide values from my database in a users table.
If my database will also be hosted in azure, how would I develop and test this locally?
Is this flow the best way to achieve the desired behaviour? If not what are alternatives?
I've done two methods when testing 'locally'.
Create an Azure Function echo API service in 'cold' mode to reduce cost. This will allow you to easily ping it and it will ping you back the content. You can also add test cases pretty easily. This isn't really 'local' but, it's low cost and allows you to collaborate with multiple team members.
Use a free web service like Post Test Server. With a couple clicks you are off and testing with lower effort. The problem with this solution is it is public so do not use any proprietary or confidential information. I've created very complex dot notation in body of REST-API technical profile via custom policies and this was effective testing data formatting and internal business logic.
Last option could be creating a web service locally on your device - I haven't done this end-to-end but you would follow this same process as hosting an application locally with localhost.
You can deploy an Azure database solely for development purposes. Or you can just mock the API response so that you can do some basic e2e testing: SPA -> B2C -> API.
So my project has got a two asp.net projects. One is for showing date(User Interface) and the another one is API(for background processes like login, database calls and etc.). Right now my app has Username and Password feature to login. I have setup a startup class in my API which authenticates the user and pass the user token. Now I want to add a feature to login through Azure portal.
Can anyone suggest me a good practice in this situation? Like I don't want to change my code and just add a feature. Should I make changes in API or Web or Both? Meanwhile I was reading about expose api in app registration. Will it be appropriate to use it just for login purposes?
Azure AD supports OAuth2, OIDC and SAML. See more information here. It is probably best to introduce the mechanism through the API first, since it would apply to the frontend as well (though slight modifications may be required there as well).
I have access to the Pinterest v5 api and have successfully authorised my Pinterest App on a couple of Pinterest accounts via Postman using Oauth2 and can run queries against those accounts. I've then created an Azure Logic App Custom Connector with Oauth2 authentication using the exact details as used in Postman (different Redirect URI of course). I can successfully add an action (List Boards) from the custom connector to a logic app. After adding the action I click the 'sign in' button on the action, the pop-up appears and I can see it hitting the right Pinterest account, but the 'authorise' window never appears, it just hangs. Postman works every time with Oauth2 but there's always issues with Custom Connectors. This is the url it's hanging on https://api.pinterest.com/oauth/?client_id=xxxxxxxx&response_type=code&redirect_uri=https%3a%2f%2flogic-apis-westus.consent.azure-apim.net%2fredirect&state=2345dfhghg2-ce76-43c5-b7bc-efbf78d4c426&scope=boards%3aread%2c+pins%3aread
Any suggestions or thoughts welcomed!
From my testing, it looks like Microsoft enforce a space between Scope entries, which prevents Pinterest from authorising the oauth2 request. The Custom Connector can work if you only use one Scope e.g. user_accounts:read. So the workaround to use a Custom Connector with oAuth2 for the Pinterest API v5 is to create a connector for each Scope you want to use.
Can anyone raise a bug with Microsoft for this? Happy to provide more detailed info, but I don't have a support arrangement with MS.
I am looking into developing integrations for the Acumatica Cloud ERP. I am developing a SaaS product on Azure which extracts accounting data from various sources. From the documentation provided by Acumatica, I can see that the API connects to a local instance of Acumatica. If I were to connect to a local instance I would need to use some sort of gateway which connects to a local machine. I also had to install a local instance myself to be able to create a client application and use OAuth 2.0.
I am having issues to understand how to create integration with Acumatica.
Do I need to know the instance name / URL of each of my clients? Do I need to have a local instance running to be able to use Acumatica APIs? Can client Acumatica instances be publicly accessed? If the client using authorization code flow, authorizes my application to extract data from Acumatica, what is the Acumatica ERP URL that I should be using? Mine or the client's? The documentation always uses localhost to connect to an API.
If you use any of the Apis provided by Acumatica:
Contract Based REST (Recommended)
Contract Based SOAP
Screen Based SOAP
You only need the a set of credentials and the URL of the site to communicate with it from the outside. By set of credentials I mean that the credentials that you use need to be able to access and perform the appropriate action on the Acumatica screen that you want to integrate with.
You can find more information on how to do so on the help web site at the following link:
https://help-2019r2.acumatica.com/(W(12))/Help?ScreenId=ShowWiki&pageid=ff22837c-cd3a-410e-b768-88ca6e53b165
It is the Development Integration Guide
Edit
Since you are mentioning Authorization Code Flow in the comment, here is the link that contains more information
https://help-2019r2.acumatica.com/(W(14))/Help?ScreenId=ShowWiki&pageid=ff780860-09c2-46c9-bdd7-c6c3b1fc442c
On that screen you will see the following information:
After the user is authenticated in Acumatica ERP, the client application receives an authorization code, exchanges it for an access token, and then uses the access token to work with data in Acumatica ERP.
Which means that even if your application does not handle the user credentials, the users will need a set of credentials in order to connect the application to the Acumatica site. The user used here will defined the access rights that the application has.
I'm working on a submission for a conference. I'd like to integrate DocuSign with Alfresco's Angular based developer framework and specifically the Alfresco Content App.
In order to keep things simple, I'd like to think about workflows that could be done 100% from the browser without any backend code of my own.
I suspect I could create a "Sign this document now" type action for any document found in the Alfresco UI. That could initiate an OAuth flow that would not require any backend services of my own.
I think I would need to put my integrator key into the SPA. This would then be visible to anyone using the app. From reading through docs, I'm unclear if it is OK to "leak" this key?
Are there other use cases I can implement in an SPA without adding backend services of my own? Things like, sending a doc out to be signed by one or more people? Or embedding a signing experience in the Angular UI?
I have seen the following series on the DocuSign blog:
https://www.docusign.com/blog/dsdev-building-single-page-applications-with-docusign-and-cors-part-1/
Having read through that and also the REST API documentation, I'm still unclear if it is even possible to implement something like this without any support from my own backend service.
I also have not found any place online where I can reach out to a developer evangelist from DocuSign to discuss my options. I believe DocuSign developers monitor SO, so figured this was the next best thing.
Great question. Browsers implement the Same Origin Policy. So, as I wrote in the blog series (see all three of my posts listed below), you will need a CORS gateway to make API calls from your Angular program running in the browser itself to the DocuSign system.
The good news is that creating a private CORS gateway isn't hard. See part 2 of the series:
Part 1. Introduction
Part 2. Building a private CORS gateway
Part 3. An example React SPA
Authentication
Your app will need an access token when it makes API calls to DocuSign. There are multiple techniques available to give your app the access token it needs:
Your app can, by itself, authenticate the user with DocuSign. In this case, because of the security issues--as you mentioned in your question--you do not use the OAuth Authorization Code Grant flow. Instead, you use the OAuth Implict Grant flow, which is designed for this use case. This flow is demonstrated in part 3 of the blog series.
You can implement the OAuth Authorization Code Grant flow in your server, and then create a private API between your server and your browser app to obtain the access token.
A private API
As an alternative to using CORS, you can just implement your own private versions of the DocuSign API methods on your server. Then your browser app would send a private_send_envelope request to your server. Your server would manage the access token, send the request to DocuSign, and relay the response back to your browser app.
This pattern is the same as your question about implementing a backend service. It will work fine but is not as elegant as implementing everything within your browser app. Depending on your immediate and future API needs by your SPA, this might be a good idea or not.
CORS support is the key
Until DocuSign has CORS support you'll need to build something on the backend. Either a CORS gateway (which only involves configuration, not software) or a private API gateway.
Please ask your DocuSign sales or technical contact to add your information to the internal DocuSign proposal for CORS support, PORTFOLIO-1100. This will help raise the priority of CORS support. Thanks.
Specific answers
Regarding:
I think I would need to put my integrator key into the SPA. This would then be visible to anyone using the app. From reading through docs, I'm unclear if it is OK to "leak" this key?
Answer: It is okay to add your integrator key (IK) to your browser app if and only if the IK is set for Implicit Grant usage (check the "Mobile App" checkbox on the IK's property sheet).
Having read through that and also the REST API documentation, I'm still unclear if it is even possible to implement something like this without any support from my own backend service.
Answer: at this time you will either need to implement a private CORS gateway or implement backend software.