How can I add authentication when using the Logic App action?
The Microsoft docs around using the action for nesting only detail making the call; nothing on adding any authentication.
I know I can use the "raw" HTTP action, but this goes HTTP, whereas the Logic App action goes direct to the workflow, i.e. no HTTP. And this means you can NOT enable the Access Control setting to limit calls to only other logic apps when run in an ISE.
We also want to move away from using the SAS key in the logic app URL, over to using the Azure AD OAuth authorisation policies for management of the authorisation
If you want to move away from using the SAS key in the logic app URL, over to using the Azure AD OAuth authorisation policies for management of the authorisation, the best way to do it would be through API Management.
At this time (2020-10-28), there is no way to add OAuth authentication to the Logic App action
You have to use the HTTP action in the logic app, which allows you to add an Authentication parameter
You can then select the Authentication Type from ...
None
Basic
Client Certificate
Active Directory OAuth (i.e. Service Principal)
Raw
Managed Identity (i.e. either User or System Assigned Managed Identity)
Related
Im trying to implement IdentityServer authorization and my scenario is below:
we have one home page for all our application "www.vision2025.com" and i have link to my mvc application "MarketingDashboard" where users are authenticated by home page and redirect to my mvc application using windows authentication. Now user can do any action in my dashboard which interact to web API.
Now i need to implemented IdentityServer to authorize all the web API call from my dashboard but no need of login.
Please suggest any idea
Thanks in Advance
I think you don't want to build IdentityServer because your enterprise company has already built ADFS (Active Directory Federation Services). You just want to ask who maintain AD and ask him to enable ADFS for OAuth2. This is a page to help you catch all scenarios here.
Because I don't know how far you can change for all applications but there are some solutions with ADFS you can go with:
Let your main server (acts as Home Page and where user redirects to ADFS to sign in) performs On-behalf-Of flow. In this scenario, your main server will be a linked server that transfer its taken access token which retrieved from ADFS. I strongly recommend this way because you just want to add as many as your new upcoming web and api. The cons are they require you ensure protect highly access token in your main server
Because OAuth 2.0 doesn't support chaining Resource Servers yet (such as you signed in Resource Server A, then use provided access_token to call Resource Server B in different clients), you need to allow your main server store his username/password (also knew as trusted back end server , means your enterprise allows this server can store client credentials). So each time you redirect user to target MVC Application, you should transfer encrypted username/password as well. Then your target MVC application can perform Authorized Flow or Implicit flow itself in Back-end code, then returned new access token to client web to perform calling Web API.
This is my current setup:
IdentityServer4
API (Bearer authentication)
SPA page (oidc-client implicit flow redirected to IdentityServer4 Quickstart UI)
Native application (written i C#)
The native application already have the users credentials. I want to provide a web link to the SPA page from the native application, but I don't want to force the user to login again when navigating to the web. Instead I want to move their current session to the web page.
Is it possible to "inject" the access token into the oidc-client? (using a url fragment). Or is there any other flow or way to make this work?
In general the answer should be: you are on a wrong way.Look: you use resource owner password flow in your native app and that's wrong. It's not interactive, meaning not only IdP has access to the credentials. In general such flow is recommended for test purposes etc, not for general use. One huge limitation of the non-interactive flow is that it does not create a user session. If you switch your native app to an interactive flow such as Code flow with PKCE extension, it will create the session. After that your other app will get authenticated automatically whenever the session cookie for Identity server is alive.NB: If you don't like to improve your architecture, you are free to do whatever you like, including providing a token in the link. That token will still be valid for calling the API. But that will be not the implicit flow, you will not have a session, nor the possibility to use silent refresh feature.
I have developer an API that is secured by oAuth2 and Azure B2C. I now want to access that API from a legacy web forms application which is using Forms as it's authentication mechanism.
I have used hellojs successfully on the client side to trigger the authentication method in a separate browser window and then use the access token successfully to call my API but how do i do this from the server side?
All the examples I've seen when setting up oAuth2 involve securing an API using the OWIN middleware (e.g. with Facebook login, etc) but I need to retain the existing forms authentication and simply invoke code that calls the API and handles the access code/token etc.
If I need the backend system to make requests on behalf of a user, should I be storing the access token securely somewhere?
The simplest approach would be to have the users authenticate against B2C separately. Think of this in terms of "linking" their account in your Web Forms app to their B2C account. If you also request the offline_access from Azure B2C, you'll receive a Refresh Token that you can exchange for a valid Access Token when needed.
Ideally, you should pivot away from Forms authentication. It's a very outdated model. It may, however, be a non-trivial amount of work which is why many folks often choose to start with the "linking" strategy and only tackle Forms Auth when they're doing a larger refactoring of their app.
We currently have a typical forms authentication setup in our organisation; with a login page located at something like account/login. We want to retain this but also want to start securing some of our APIs with OAUTH2 ; essentially we are the provider.
From reading a fair bit about the subject Microsoft's OWIN OAUTH implementation moving forward isn't supported (e.g. vNext) and doesnt support all the flows with OAUTH2. Thinktecture's identityserver3 seems to be the "standard" and most complete solution there is currently.
I cant seem to find an example of using identityserver3 with an existing app that requires forms authentication.
We would be looking at using it in two different ways; one using the implicit flow using javascript where we allow a third party site to call our API once the user has logged in to us (using the forms auth) and the user has allowed the client to access specific scopes.
The other use case, I think , would use the authorisation code flow ; the client would be requesting this so it can auto login (much like a login with Facebook - but login with X company) or be already logged in if logged in our site.
Any help with these scenarios would be most appreciated.
I think it will not be possible to switch your app to OAuth without changing your existing login.
I would suggest you use Identity server with custom user store(https://identityserver.github.io/Documentation/docsv2/advanced/userService.html) to use your current user database. That way your existing login accounts will be used by the identity server.
You can then secure your APIs with OAuth using the Identity server. You might need to change the way your current app call the APIs too. This means users of the current app will be redirected to identity server's login page. You can brand your login pages using custom views to make it appear similar to the curent login page (https://identityserver.github.io/Documentation/docsv2/advanced/customizingViews.html)
For my current work project we're trying to use OAuth to secure a mobile API, but the app doesn't have user accounts, so authentication would take place invisibly from the user, where the app will send up some secrets to the server and receive the token to be used for subsequent web service calls. The problem is, all the libraries and tutorials I can find implementing OAuth follow this pattern:
Present a web view allowing a user to login
Receive a callback to a custom URL scheme, and parse the necessary information to authenticate future web service calls
How do I achieve this without the webview step? I should be able to make an HTTP request directly with the correct credentials which will return the necessary authentication details.
The app will use OAuth 2.0
It is not clear what do you mean by
the app doesn't have user accounts
If you want to call some API on behalf of user you should ask him for a password. Doing it in webview or not depends on provider implementation. For example, twitter doesn't force you to do that.
In other case, if you want to call service on behalf of client, take a look at this answer: https://stackoverflow.com/a/7477112/2283405
If the app doesn't require "personalised" or "user-specific" data to be manipulated, then you can probably try using "client-credentials" grant type to obtain access tokens using the application credentials granted upon the application registration process by the Authorisation Server (for e.g.: OAuth server) that's there in your environment. The idea is that, your app is what basically authenticates with the Authentication Server for you using the aforesaid credentials (i.e. Client Consumer Key and Client Secret Key).
NO, you have to do login compalsary. if you try without. it won't be possible.