We're developing an API and it uses authentication.
During development and debugging I'm constantly starting the api, sending requests with postman etc. But we also use Swagger and I would like to be able to just click on some GetMethods to free up my postman tabs a little.
I know this goes against what authentication is about, but can i set a default user or a default token? I know I can add authentication to swagger and paste in the token, but I would need to do this every time.
I would assume there'd be a simple option to set a default during debugging, but I cant find anything. Is it just not possible?
I also thought about simply not using Authentication when started in debug, but a lot of controller actions need the logged in user.
Related
I've created a new Blazor app using the Visual Studio template adding B2C using the wizard during the project creation.
All works great with authentication. I can sign in using my favorite identity provider and receive the id_token. I don't know where I can get the id_token, but I can see the claims in my user identity.
What I need help with is how do I take the information in the claims to acquire the access token. I need this token to call my endpoints.
This seems like it should be straightforward and a common thing, but I can't seem to find any good examples.
In a normal MVC app, I can get this through the ConfidentialClientApplicationBuilder.AcquireTokenByAuthorizationCode but that doesn't work in Blazor (unless I'm doing something wrong).
I've tried this: https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-access-tokens
I think it'll work. How do I get "code"(id_token) in my blazor app? It's what is decoded behind the scenes and all I can find are the claims resulting from decoding the "code".
I've used the azure's "Run user flow" to access an example id_token("code") and pasted it into my project and made the call in the link above and it seems to work. I'm running into permission issues, but it's at least a successful call.
Maybe if I can just get access to the id_token I can make it work from there?
This seems like a client side app, similar to a SPA. In which case you must use the implicit flow, where the response type is “id_token token”, and returns an id token and access token to the browser in one call. This isn’t an exact answer, but only our MSAL.js library can make this type of call, but Blazor seems to use C#, and msal .net does not do client side auth calls. acquireTokenByAuthCode() would work client side as long as you register the app as a native app, so a secret is not required.
I have used the ASP.NET Core React project template to create a web application into which I've installed Identity Server 4. The React app takes care of all the user interaction, with the dotnet application used as an API only. I've integrated a Google OAuth2 authentication option using the services.AddAuthentication().AddGoogle builder extension provided by Microsoft.AspNetCore.Authentication. Finally, the whole thing is containerised and deployed to a Linux App Service on Azure.
Most of my code was ported from a previous version which was a very similar setup but in that case I'd added a custom React app to an existing ASP.NET application rather than start with the official React project template for dotnet. Back then everything worked well. But I'm facing problems with my new version when deployed to Azure. Here's a Fiddler trace to highlight the issue:
vault2 is a client of the identity service. identity-azure is the Identity Server application. The flow this trace shows is as follows:
User clicks Sign In on the Vault application
Browser is redirected to the Identity application
User clicks the Google button to initiate the OAuth2 flow
User signs in with Google account
User is redirected to the default callback URL (https://identity-azure.<domain>.com/signin-google?state=...)
This last step is where the problem is. You'll notice that you don't see the callback URL in the Fiddler trace, but instead you see a couple of other requests (e.g. service-worker.js) which are clearly being made from the React app. So the signin-google path is being handled by the browser's cached React app and not the server. The React app uses react-router-redux to handle certain routes client-side, and of course signin-google is not one of these so it appears to be returning an empty component.
As far as I can tell, all my ASP.NET routes (implemented using the Route attribute to decorate controller action methods) are handled consistently by the server. However, the signin-google route is implemented in the authentication middleware so as far as I know I don't have much control over it other than to change its path. Is there something I can do to force this to be handled server-side?
I should add that this behaviour is quite erratic. It seems that if my Google account is signed out then the above is observed, but if my account is already signed in then signin-google returns the expected 302 status code and the OAuth2 flow continues successfully.
I finally worked out what was going on. At least, I think I have. I can't be certain because I've since broken the React UI out into an entirely separate application but I was observing a similar pattern there. There was even a clue in my original question! Turns out the breaking pages were actually being served from the React app's service worker. I discovered this because even after breaking the React app out under its own domain leaving my identity-azure domain a pure ASP.NET Web API, requests for certain URLs under identity-azure were still behaving the same and I eventually noticed they were reporting themselves as being served by ServiceWorker on my browsers's Network tab. Example below.
As soon as I cleared the browsers application cache (in Chrome on Windows this was F12 > Application > Clear storage > Clear site data with Unregister service workers checked.
I'm not 100% sure what the solution would be if I'd left my React app in the same solution as the ASP.NET backend, but I presume it'd involve excluding specific URLs from service worker. I hope this helps someone in the future.
By the way, if you're thinking of building a fully decoupled UI for Identity Server 4, there's a great starter example here.
I have Asp.Net 4.6 webAPI application workking with JWT. I am using the Okta authorization code flow/token exchange to get the token. I then use the token in all my requests. Everything works fine when using my Okta dev endpoint, but when I use our production Okta endpoint, authenticated requests fails. The authorization, and code/token exchange works fine, but when I request data to my WebApi controller with the [Authorize] attribute, the request doesn't seem to return anything, even an error. In fact the request in chrome shows that the request never finishes. (Though the preflight OPTIONS request does get a 200). I can also see the request in Wireshark, and that a response is never sent.
The most obvious answer is that there is something I have a configuration issue either in my code, or or on the production Okta endpoint which is causing the Authorize attribute to silently fail. But my main concern is that I can't seem to find a way to debug it. I tried inheriting from the Authorize attribute, and overriding all the methods to see if I can determine anything by putting breakpoints in those methods, but the methods OnAuthorization, IsAuthorized, HandleUnauthorizedRequest, etc seem to never get called.
Which is the best way to debug there? Is there an Asp.Net event I can hook into to see what is being sent/returned to Okta to validate the incoming token?
Why is it silently failing? This seems like an error that by design should bubble up.
This most probably is because your production does not have API access management. In your preview org. you have API AM for free thus it works. In your production org. you gotta buy the feature. To test on each org. go to Okta admin dashboard > security > API. You might see "authorization servers" tab for one but not the other.
Another issue might be, if your issue is your Org. URL then Okta does not give out the key to the token cannot be verified locally.
it is hard to say without looking at your configuration but the above two scenarios are very common
I am trying to work with the asana API in my C# Windows Application and have several questions I'd like to ask.
When you register your application with asana, it wants to know APP NAME, APP URL, REDIRECT URL. If it's a windows application, what values might I supply for the second two prompts?
When that is entered, you get a client id and a client secret. Is this completely different than the apikey? Is the former for OAuth and the latter for asana, or does asana work in conjunction with OAuth?
Basically I want to take a request like this: https://app.asana.com/api/1.0/tasks//stories?opt_pretty and get back in my application the same json I see when I issue the request in my browser.
You can provide localhost
You should definitely have a look at https://asana.com/developers
Your answer is there https://community.asana.com/t/can-a-windows-application-be-registered/23381 !
Good luck ;)
I'm currently attempting to use the OAuth 2.0 User-Agent Flow with a clientside C# application, and I'm running into some confusion relating to the redirect URI.
Because I'm working with a clientside application, I cannot supply a standard redirect URL to a web server. However, according to the people I'm trying to authenticate with (Salesforce, in this instance), the User-Agent Flow is the correct one to use for a clientside application.
My question is, what can I do to catch the access token in this situation? Apparently I can create a "local resource accessible to the client," but I'm unfamiliar with the mechanics behind this, and I can't find any resources on the topic (partly because I don't know what to look for).
Any pointers as to where I should start looking would be greatly appreciated.
Edit: Some more digging has revealed the following stackoverflow question:
How do I develop against OAuth locally?
I'm doing some more investigating with what they suggested, but any other suggestions would be great as well.
Edit: Some more searching revealed this article:
http://sarangasl.blogspot.com/2010/09/create-simple-web-service-in-visual.html
Still feels like I'm poking around in the dark without an understanding of the larger picture, but I believe I need to set up a local web service using localhost and point my redirect URI there. I'll then use my web service to unwrap the response from the OAuth server and have my application respond appropriately. More updates to come.
Ooookay. So from what I've been able to gather, I need to set up a local web service to supply as the callback for OAuth. I need to listen on said web service myself and catch the callback to pass it to my app. However, the default ASP.NET web service provided by VS2010 does not support URL parameters, just API calls, so I apparently need to use the WCF Rest starter kit instead.
I am completely foreign to all of this, so any tips would be a godsend at this point. In general, I'm thinking I set up a local WCF Rest service, supply that local URI to OAuth as the callback, and then catch the callback URL using the Rest service. Then I parse the URL and extract the access token. At this point, does my app request the access token, or can my web service "give" the token to my app? I.e., where should the locus of control be?
Figured out a clever way to work around this. Instead of setting up a service to listen for OAuth's redirect URL, I embedded a WebBrowser control inside my Windows form.
I pointed this embedded WebBrowser to the authentication URL and let the user log in and authenticate with Salesforce and grant permissions to my app. Then, I let Salesforce redirect my embedded browser to a dummy redirect URL that I supply. This redirect never actually goes anywhere, it just shows up as a 404.
However, by monitoring WebBrowser.Url, I can pick up the entire URL that my embedded WebBrowser control is directed to, including the access token that is appended by Salesforce. Basically, after the user authenticates and grants permissions, the embedded browser is redirected to "http://www.dummyurl.com." Salesforce appends the access token, so WebBrowser.Url ends up looking something like this:
http://www.dummyurl.com#access_token=ABCDEF&instance_url=ABCDEF
From here, I can just parse the URL and go on my way. No third-party web server or local web service required. :)
The call the Authorization type you need Authonomous Client http://wiki.developerforce.com/page/Digging_Deeper_into_OAuth_2.0_on_Force.com#Obtaining_a_Token_in_an_Autonomous_Client_.28Username-Password_Flow.29. Read about the URL you have to send there.
grant_type=password&client_id=<your_client_id>&client_secret=<your_client_secret>&username=<your_username>&password=<your_password>
You can use DotNetOpenAuth library. There's an example using WPF, where it uses a winforms control called ClientAuthorizationView provided by DotNetOpenAuth library.
It is a control that hosts a browser allowing the user to authorize the client without leaving the application.
Hope this help.
Regards