I am getting 2 different issuer in the token when i hit the same url of my app service.
I have apigee and the backend azure app service with the runtime stack netcore2.1 Identityserver is integrated with default issueruri. we never overrides issueruri.
App service have the custom domain like xxxx.local.com and apigiee have the url like dev1-xxxx.com. The token endpoint dev1-xxxx.com/token which will generate the access/security token from idservice.
with the above config we are getting the indeterminate issuer in the generated token. one time dev1-xxxx.com (this is the apigiee url) and another time xxxx.local.com (this is the app service custom domain). what could be the issue in our code?
in the appinsights log i can see the some requests are logged as apigee url one ore more request are logged with direct url (app service)
Related
I have an API that implements OAUTH Azure Active Directory Authentication. To achieve this, I created 2 App Registrations: Client and Backend.
I successfully implemented a Logic App able to call the API, so I am sure the authentication flow works.
Now, I need to call the same API from Power Apps, but unfortunately I got an error.
First, I create a Custom Connector
Then, I configure the Security section in this way:
Client ID: it's the ID of the Client App Registration
Client Secret: it's the secret of the Client App Registration
Login Url: login Url from Microsoft
Tenant Id: it's the Tenant Id of App Registrations
Resource URL: I don't know what to put here, I tried by using the ID of the Backend App Registration
Scope: It's not mandatory, but I tried to set the Application ID URI of the Backend App Registration concatenated to /.default.
When I try to create a Connection at the end of the wizard
I get this error
AADSTS650052: The app needs access to a service ("http://rts.powerapps.com") that your organization "a467080d-9919-4241-a48f-8b0002685a59" has not subscribed to or enabled. Contact your IT Admin to review the configuration of your service subscriptions.
My Client App Registration has the following API Permissions
UPDATE
Following #ChauncyZhou's suggestion and adding the Redirect URL generated by the Custom Connector to Client App Registration, I completed Custom Connector and Connection creation process.
When I test the API I get a 401 error:
The audience '97e**********************9c9' is invalid
Where 97e**********************9c9 is the Backend App Registration id. Did I make some mistake when I configured the Custom Connector? API works fine with Postman and Logic App.
When you call the same API from Power Apps, you don't need to add
Powerapps Runtime Service permission.Because you are calling your own api,Not calling the Common Data service api.
Because you add this permission, but your organization has not subscribed to or enabled, so it causes an error.So for your question, you just need to remove PowerApps Runtime Service permissions.
I currently have the following architecture
APP -> API -> KeyCloak
I want the APP to be able to send requests to my API which will then internally proxy certain requests to KeyCloak. For example, I'd like to make a request to the /userinfo endpoint in KeyCloak through my API. If I can figure this out I can then perform more complex features.
APP -> http://api:port/api/userinfo
API -> http://keycloak:port/auth/realms/quartech/protocol/openid-connect/userinfo
I have a valid JWT Bearer token. As I can directly make the request to KeyCloak successfully, however if I attempt to make the request via my API it returns 401. Even though it is using the same JWT Bearer token.
I believe it has something to do with configuring the KeyCloak client to allow requests to come from the API. But so far I haven't been able to figure it out.
I've discovered it required a DNS entry to local development within a Docker container.
I've edited the hosts file and added a 127.0.0.1 keycloak and then al
From AWS docs,
AUTHORIZATION Endpoint
The /oauth2/authorize endpoint signs the user in.
GET /oauth2/authorize
The /oauth2/authorize endpoint only supports HTTPS GET. The user pool client typically makes this request through the system browser, which would typically be Custom Chrome Tab in Android and Safari View Control in iOS.
LOGIN Endpoint
The /login endpoint signs the user in. It loads the login page and presents the authentication options configured for the client to the user.
GET /login
The /login endpoint only supports HTTPS GET. The user pool client makes this request through the system browser, which would typically be Custom Chrome Tabs in Android and Safari View Controller in iOS.
Both endpoints redirect after success, which one to use when?
The difference I noticed is if you have only one identity provider enabled the /authorize route will skip the hosted UI. The identity provider must be a Federation one for this to work. If the identity provider is Cognito you'll still be redirected to the hosted UI to type your password.
I have a web app front end and web api back end both written in ASP .Net Core 1.1 MVC. I am using Auth0 as the authentication server, using the "authorization code grant flow".
So the user logs in - i.e. the user gets directed to Auth0's login screen, which, if the username and password were correct, sends the web app back an authorization code, which the web app then exchanges for an access token, which is then used for all web api calls.
Then, the user clicks on a link which makes the web app call upon a web api action. My question is, how can the web api know which user is making the request? Or maybe at the point the user successfully logs in, the web app should call upon a controller in the web api and tell it which user just logged in? Not sure what the best practice is...
Thank you
I will answer in terms of OAuth 2.0 specification.
Specification determines 4 roles:
Resource owner
Resource server
Client
Authorization Server
In your context:
Resource owner is end-user.
Resource server is your Web API.
Client is your web application.
Authorization Server is Auth0.
Follow steps:
Your Web API should be registered on Authorization Server
(https://auth0.com/docs/apis).
Your Web API should be responsible to validate access tokens that
are used for requesting API. This access tokens contains info about
end-user/client (https://auth0.com/docs/api-auth/tutorials/verify-access-token).
You should include Web API scope in authorization request.
You should get access token in your web application and include it in HTTP request to Web API.
I have a combination Web API and MVC application that is secured using Azure ACS, Windows Identity and passive redirects. This works well. Now I am adding a mobile application using PhoneGap that makes calls to the existing application's API. I having trouble figuring out how to implement authentication on the mobile client. I've got it mostly working, but I can't get the token to client due to the Return URL setting in ACS. The scenario is:
Mobile client sends get request to API
API responds with 401 if user is unauthorized
Client redirects to ACS login page and user authenticates
Token is sent to the Return URL which is the application running on a web server
For example, if I'm running the client app on localhost:63327, the token is sent to localhost:58392 because that's what is set as the return URL in the ACS configuration.
How do I get the token to my mobile client?
I see that people did not really understood your question.
This solution might work.
In a nutshell, is to add a new protocol to get the authentication token from the server to the app client.
PG App calls a web method registering a request to Auth:
POST BeginGethAuthToken
id = pickup Guid
pswd = pickup Password
BeginGetAuthToken can be a web method in your login page.
Server associates the pickup guid with the pickup password
PG Apps start the authentication flow by opening the log-in page using the InAppBroser
mywebapp.com/AppLogin.aspx?id={pickup guid}
The pickup guid is set as a cookie for your webapp domain.
User completes the authentication using the InAppBrowser.
AppLogin.aspx on successful authentication associates the pickup guid with the authentication tokens and ask the user to close the browser to go back to the app
the PG App picks up the authentication token by providing the pickup password.
note that for security the server needs to add expiration policies of pickup guids such that only one app can use a guid at a time and restart the process in case of collisions.
You effectively need to pre-authenticate your client. See http://blog.siliconvalve.com/2013/06/25/protect-your-asp-net-web-api-using-azure-acs-service-identities/