Authenticating in Azure but calling web api on localhost - 401 - azure-mobile-services

I have an Azure mobile app authenticating on azure with FB and Twitter. I am able to login to both but when testing web api calls locally (hosted in IIS) - any controller with the Authorize attribute - returns a 401.
The alternateLoginHost is set to the Azure host and it is providing me with a token after a successful login.
I followed the instructions in the docs about setting up Local debugging with authentication.
It is using attribute based routing - config.MapHttpAttributeRoutes()
Here is my full OWIN startup class
public class OwinStartup
{
public void Configuration(IAppBuilder app)
{
HttpConfiguration config = new HttpConfiguration();
config.MapHttpAttributeRoutes();
new MobileAppConfiguration()
.ApplyTo(config);
app.UseAppServiceAuthentication(new AppServiceAuthenticationOptions()
{
SigningKey = ConfigurationManager.AppSettings["authSigningKey"],
ValidAudiences = new[] { ConfigurationManager.AppSettings["authAudience"] },
ValidIssuers = new[] { ConfigurationManager.AppSettings["authIssuer"] },
TokenHandler = config.GetAppServiceTokenHandler()
});
app.UseWebApi(config);
}
I have seen references in the documentation about either using the global http config passed in from asp.net or creating a new one - I tried referencing the GlobalConfiguration.Configuration instead of creating a new instance but it didn't help.
Is there a way to hook into the OWIN pipeline to see if the token is making it to the app service authentication module?
[EDIT] ZUMO AUTH HEADER
I am also adding the x-zumo-auth header and setting it's value to the token from the current user like this
request.headers.append('X-ZUMO-AUTH',
app.azureClient.currentUser.mobileServiceAuthenticationToken)
And I can see it in each request being made to the api. A call to the endpoint https://mysite.azurewebsites.net/.auth/me using this mechanism is returning a correct response so I know the token is valid.
[EDIT] Verified working in Azure after adding ZUMO Version Header
deployed the web api to azure and tried to call my web api endpoint and received a bad request error. It turns out it required an additional header for the version
'ZUMO-API-VERSION', '2.0.0'
I added the header and it worked.
Tried the local call again with the version header but still getting 401.
All I can assume is the OWIN middleware is not receiving the token probably due to a config problem - need some transparency into the pipeline to test some of these theories - not sure the best way to do that
Not sure where to look next in solving this.
[EDIT] OWIN Pipeline Authenticate stage Hook
OK - figured how to set up the equivalent to asp.net pipeline event handlers in OWIN - in my startup file I added this code to execute when the Authenticate stage is reached
app.Use((context, next) =>
{
return next.Invoke();
});
app.UseStageMarker(PipelineStage.Authenticate);
Added a breakpoint and when the debugger stops I can see that in the call stack
that the Azure App Service Middleware in in the pipeline
Microsoft.Owin.Security.Infrastructure.AuthenticationMiddleware
<Microsoft.Azure.Mobile.Server.Authentication.AppServiceAuthenticationOptions>
.Invoke(Microsoft.Owin.IOwinContext context)
Confirmed OWINContext.Request.Headers Contains the Correct Auth Token
Looking in the debugger the token is indeed in the Context.Request.Headers collection at the Authenticate stage of the OWIN pipeline and it has the correct value. For some reason still receiving the 401 status
I doubly checked the value I am using for the SigningKey - copied from the WEBSITE_AUTH_SIGNING_KEY value in Azure.
[EDIT] Debugging with source and exception being thrown in ValidateIdentity
AppServiceAuthenticationHandler.ValidateIdentity
Downloaded source v1.1.157.1, loaded symbols from symbolsource but those are marked as 1.0.157.1 and visual studio is complaining that the source is different than when the module was built. Because of this I cannot step through the code to see the exception that is being caught.
[EDIT]Built and Referenced v1.1.157.1 DLL - exception type now visible
In the ValidateIdentity method when it calls
options.TokenHandler.TryValidateLoginToken
The following exception is thrown
"Could not load type 'System.IdentityModel.Tokens.JwtSecurityToken'
from assembly 'System.IdentityModel.Tokens.Jwt, Version=5.0.0.127,
Culture=neutral, PublicKeyToken=31bf3856ad364e35'."
[EDIT] Finally found and fixed the issue
There was an issue posted on GitHub for IdentityServer having to do with a breaking change with a nuget package - going from v4 -> v5 of System.IdentityModel.TokensJwt package.
https://github.com/IdentityServer/IdentityServer3/issues/3017
I downgraded my install to v4.0.x and it fixed the exception and also fixed the 401 errors I was seeing when running locally.
All is good now

Do you have the correct app settings for authSigningKey, authAudience, and authIssuer in your web.config?
FYI -- a good writeup of the setup is here in case you haven't stumbled upon it yet: http://www.systemsabuse.com/2015/12/04/local-debugging-with-user-authentication-of-an-azure-mobile-app-service/

Is your localhost serving https traffic?
If a controller is decorated with [Authorize] it will require that the request/response occurs over https.
If you're targeting http://localhost, [Authorize] will cause a 302 to https://localhost.
This 302 can break the auth process. The solution would be to serve https locally, point your client to the appropriate port (my box uses :44300), and try it out again.
Also, make sure any relevant redirect URLs go to the https:// version of the URLs you're using.

Related

Nuxt & Strapi - Logging in with OAuth using Github

I am setting up a community website with a Strapi CMS backend and a NuxtJS frontend using the composition API.
Besides the normal registration and login using email and username (which works!), I want users to be able to login using GitHub.
I am using #nuxtjs/auth module for authorization.
I've "deployed" my Strapi backend using ngrok. This is needed apparently to make OAuth work.
I've set up my GitHub application, using <ngrok-url>/connect/github/callback as the callback.
I've set the GitHub client_id and secret in my .env file.
In the strategies in my nuxt.config.js file I have this:
github: {
clientId: process.env.GITHUB_CLIENT_ID,
clientSecret: process.env.GITHUB_CLIENT_SECRET,
},
I've added a line in config/server.js of the Strapi backend:
url: '<ngrok url>'
So the backend is fired up in that location.
In my Strapi configuration, I've enabled a GitHub provider, and I need a redirect url to my frontend there. I am not sure what to put here.
I've tried: http://localhost:3000 (my Nuxt app port), but then I get a redirect uri mismatch error ("the redirect uri must match the registered callback"), when I try to access it from the frontend (using nuxt-auth's loginWith('github)').
More info on this here, but I don't get what they are saying.
Provide a redirect_uri where?
And they say to have a redirect_uri that matches what you registered. That matches what exactly?
The nuxt-auth docs are not that elaborate, saying to use $auth.loginWith('github') and that's it. I do this in my frontend, but I'm not sure if that is all I should do.
I can go manually to "<ngrok-url>/connect/github" (in ingognito) and login there in GitHub and I get redirected to the url I put in Strapi, with the access token as a parameter. So that part seems to work.
My main 2 question are:
How do I make the correct call from the frontend to the right endpoint to login through GitHub?
How do I process the result of that call?
Any help is much appreciated!
Update #1
I added a property redirectUrl on the github strategy in nuxt.config.js with the <ngrok-url>/connect/github/callback. That fixes a redirecting issue from GitHub.
I also added a redirect in Strapi to localhost:3000/connect/github and added a page in nuxt following this solution.
Now, I get back a jwt token and a user from Strapi, but $auth.loggedIn is still false in my front end. I'll try to fix this by writing my own middleware. I think this is needed because the app is server-side rendered.
The issue was that loginWith('github') connects nuxt directly to github. But we want to go to Strapi first. So in the end, I removed all the github-related info in my frontend and made a regular <a> with href to <strapi-url>/connect/github and then handled the response in a vue page like so:
data() {
return {
provider: this.$route.params.provider,
access_token: this.$route.query.access_token,
}
},
async mounted() {
const res = await this.$axios.$get(
`/auth/github/callback?access_token=${this.access_token}`,
)
const { jwt, user } = res
await this.$auth.setUserToken(jwt)
this.$auth.setUser(user)
this.$router.push(`/`)
},
To test it locally, I used ngrok to fire up the backend in a tunnel, instead of localhost.
If you want to look at more code, check out my PR here

400 status on login request for asp.net core 2.0

I have the following issue.
After upgrading an application to ASP.NET 2.0 I get a 400 (bad request) status response whenever trying to authenticate in production.
This error does not reproduce locally and doesn't reproduce when using the production container locally.
The only difference that exists between production and local is that there is a reverse proxy in production that implements SSL for all requests.
I've tried moving the authentication code from middleware (as it was initially implemented) into a controller and I've changed the path to the route that was used for authentication. I still get the error.
All other requests work fine (provided you have a jwt token attached to them).
I should also mention that the CORS headers aren't set on the 400 response.
Any ideas?
This issue was caused by an upstream reverse proxy that was stripping some headers from the requests. Requests with verbs Post & Put were affected.
Set the log level of your application to Information to see what Kestrel is actually complaining about.
In our case we had to switch hosting providers because of the issue.

DocuSign JWT access toke call fails in Dev environment while successful in Local

We are trying to integrate with DocuSign, and using JWT authorization in Spring Boot application.
When I am running my application locally (running in local Tomcat) I am able to connect to DocuSign and email documents successfully. However, once I deployed the code to our Development environment (running Websphere), the call to request JWT token is returning below Exception. Keep in mind I am using the same base URL and Integrator key in both environments:
Exception: Error while requesting server, received a non successful HTTP code 401 with response Body: '{
"errorCode": "PARTNER_AUTHENTICATION_FAILED",
"message": "The specified Integrator Key was not found or is disabled. An Integrator key was not specified."
}'
Call to request JWT token:
ApiClient apiClient = new ApiClient(BASE_URL);
apiClient.configureJWTAuthorizationFlow(currentDir + PUBLIC_KEY_FILENAME, currentDir + PRIVATE_KEY_FILENAME, OAUTH_BASE_URL, INTEGRATOR_KEY, USER_ID, expireIn);
BASE_URL = https://demo.docusign.net/restapi
OAUTH_BASE_URL = account-d.docusign.com
I have values set for the rest of the variables as well; I'm just showing variable names only here.
I have already granted access by making the following call and logging in the browser by making the following call in a test class:
String oauthLoginUrl = apiClient.getJWTUri(INTEGRATOR_KEY, REDIRECT_URI, OAUTH_BASE_URL);
Desktop.getDesktop().browse(URI.create(oauthLoginUrl));
I'd appreciate any help. Thank you.
After days of trying out different things finally resolved my issue, posting the answer here in case it helps someone else.
In my dev env even though file name was loaded correctly apiClient could not load the correct file, and in local tomcat server that was not the case. After seeing the same exception when I changed the fileName in for local server, made a guess that server is failing to read the correct key files.
Instead of passing the file name directly I had to use Thread.currentThread().getContextClassLoader().getResource(publicKeyFileName).getPath(); for both public and private keys and that resolved the issue.

Issue in calling the OneDrive for Business REST API to upload image files

I am facing the issue in calling the OneDrive for Business API to work. Below are the steps I have followed till now:
Created a Web App/API application in Microsoft Azure Portal (A very tricky process). Gave all the permissions.
Got Application ID (A_ID) from there.
Went to the URL to get the 'code' via browser:
https://login.microsoftonline.com/common/oauth2/authorize?response_type=code&client_id=<A_ID>&redirect_uri=<URI>
Got the code. Did a callout via POSTMAN (using the code, client ID, client secret and redirect URI) to the URL: https://login.microsoftonline.com/common/oauth2/token
Received an Access Token (AT) and other details.
NOW, when I want to use this AT to upload a file, I am getting the error. The URI is: https://<tenant>/_api/v2.0/me/drive/root:/Abc.txt:/content. For headers, I am passing: Authorization-> Bearer AT; Content-Type -> application/octet-stream
The error is:
{"error":{"code":"unauthenticated","message":"Token contains invalid signature.","innerError":{"code":"invalidSignature"}}}
I don't know where the issue is. Is it in the tenant name I am using (There is a chance that I might be using it wrong!) OR is it in the permissions OR I have not set up the app in the Azure Portal correctly OR is it something entirely different.

Issue Testing after IdentityServer3 Deploy

After going through walkthroughs I had a test mvc app, test web api, and identityserver3 all working perfectly on my machine. I deployed IdentityServer3 to our servers in AWS behind a load balancer. I followed all the instructions in the Deployment wiki. I am able to hit the .wellknown configuration fine after deployment from a browser on my machine.
I changed the authority url for the mvc and api test apps to point to the aws deployment. Clients, Scopes, users, etc are all configured identically as they are hitting the same database as it was when running on local machine.
I can get an access token using RequestResourceOwnerPasswordAsync just fine so I think ids is installed fine.
However, both the API and the MVC app just trying to use implicit flow are now failing. FOr instance, when I try to hit a mvc controller action marked with [Authorize] I get an error stating "An invalid request URI was provided. The request URI must either be an absolute URI or BaseAddress must be set".
If I try to hit the webapi from the mvc app (both running locally on my machine) after a successful RequestResourceOwnerPasswordAsync call, I get the error "Response status code does not indicate success: 401 (Unauthorized)." after what seems like a timeout.
Any help would be greatly appreciated.
Figured out the problem. When specifying PublicOrigin, it has to be a full URL and not just the domain. I had left off https:// prefix.
The web api issue was related to connectivity to the identity server. There was some incorrect proxy settings for the app.