I am developing an application on WPF in order to quickly work with a web application via api (clarification: login and password are required for authorization). The essence of the api work is to substitute the generated token to the method, which is updated every 4 hours.
I can manually log into the site every 4 hours and collect this token from devtools, but I would like to automate this process and write a small console application that would automatically collect this token.
I tried to find a suitable solution for me, but unfortunately I did not succeed. Is there a way to do this?
P.S. The authorization page has its own yurl. After successful authorization, redirection to the service occurs.
Open your browser DevTools and capture the request which leads to the Token. Then write a code in your console application to call that request with HTTPClient or whatever library you want and you have the token to work with.
Related
As Discord rolled out (now for quite some time) the possibility to login to an application using OAuth from within the desktop/mobile apps themselves, without resorting to browsers (which is a pain for mobile users...), I was wondering if this was possible to pull off in ASP.NET Core.
Take this generic Discord OAuth URL, that you'd encounter inside the Discord app : https://discord.com/api/oauth2/authorize?client_id=803761073412898878&redirect_uri=https%3A%2F%2Flocalhost%3A5001%2Fsignin-oauth2&response_type=code&scope=identify
So far, using this works flawless from within Discord, as it prompts the user for Auth, and redirects to the URI set prior within the link once you hit Authorise :
Sadly, this will result, once it hits the ASP.NET app, in a 500 error on the callback when using the AspNet.Security.OAuth.Discord package. The reason being, there is no OAuth state attached to the link. Therefore, the library throws an exception outright, given the security implications.
My question then comes: Is it possible to somehow pull of this kind of authentication from within the Discord client, unattended by the ASP.NET app? Can state be bypassed from within the client, provided CSRF attack mittigation isn't compromised?
I'm open to suggestions, both on the feasability, workarounds, and possible architecture of such a solution, as this can better help Discord-to-App authentication and interactions.
I have a web app wrapper for my PowerApps app (I have embedded it as an iframe on the home page of my ASP.NET Core app).
I also have the credentials of the Azure organization that developed this application and has access to it.
So, for the first time, my built-in app asks for an email and password to sign in to a Microsoft account. And only after a successful login, I can work with it directly.
But that's not what I want.
I expect to be able to work with the application when I load this page.
So, is there a way to use the app directly without signing in to a Microsoft account?
I got the idea to make a request to the Azure AD API and get a bearer token or cookie from there, and then save it to the client, supposedly filling out a login form and clicking the login button, but "quietly".
To be honest, I don't know how I can do this. I've spent hours researching this problem, but haven't found a suitable solution.
Could you help me?
Thank you in advance!
Use ROPC flow, you just need to send a http request, then get the response.
There will be no pop-ups requiring you to log in.
Tips：
Http Request
Http Response
Related Posts:
Is there a way to improve the performance of MSAL-browser js login?
I'm building an application in WPF that is client side and will only depend on external API.
To this point I could use open API which I build in RestSharp and everything worked well. But from last week this API uses CAS authentication, so to use them I need to be authenticated. API I want to call is in external server. They have two API's and my assumption is that if I will log in on their site using CAS then I will be able to use this auth for my API calls for second API.
I'm new to SSO, CAS and security overall, so this was my first thought: I will build WebBrowser control, get returned TGC cookie and use ticket from it to use in requests I will be making. But this failed, setting cookie still got me and 401 error and from what I understand from CAS auth for now, TGC is a go to for checking if I'm an authenticated user in current session?
My next thought was to use some CAS c# library. Unfortunately all of advices / libraries focus on creating CAS in .NET projects. Is there some library which will provide a way to log in to CAS auth and then allow me to make API calls?
I hope this makes sense and I didn't messed up things completely. I'm new to secutity and I will be grateful for any help or guidance how to approach this problem. Things I have: API specification (endpoints paths) and username and password to log in to the system.
I wrote a web application which connects to the Salesforce API using the OAuth 2.0 web server flow, and that all works fine.
But now there is a requirement to access the Salesforce API from a WinForms desktop application and I'm stuck. Salesforce suggest using the User-Agent, or implict, flow for desktop applications.
The flow is described by Salesforce here - https://help.salesforce.com/articleView?id=remoteaccess_oauth_user_agent_flow.htm&type=5
I've created a WinForms application and used the CefSharp library to embed a browser. I can open a web page in the embedded browser using the URL syntax shown in the article, e.g.
https://login.salesforce.com/services/oauth2/authorize?response_type=token&
client_id=CLIENT_ID&redirect_uri=REDIRECT_URI
But I don't know where to go from here.
I'm guessing the redirect URI has to be a public endpoint, but how would the token returned by Salesforce to the URI finds it's way back to my desktop application so it can be used in the headers of WebRequests to access the API.
I would be grateful for any help, pointers, sample code, etc.
Thanks.
redirect uri doesn't have to be public. It can be localhost:somePort and your application would have to be listening to traffic on that port.
For example if you want to develop SF code using SFDX CLI + Visual Studio Code - there's a nice way to authorise access to SF org where you type your credentials on the website but when all is good - the OAuth piece gets sent to localhost:1717. As long as nothing else is listening on this port you're fine. Similar with Salesforce Data Loader - you can type username and pass to it but it also has this web-based flow. And sometimes it's the only option really, if your SF admin enabled Single Sign-On that authenticates against Active Directory/Google/Facebook/... - you might not be able to use SF username and password.
My C# days are long gone but listening on a port on local machine shouldn't be the end of the world? You shouldn't need a full-blown web server bundled with your app...
https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-implicit-grant-flow has some good theory
https://learn.microsoft.com/en-us/dotnet/api/system.net.sockets.tcplistener?redirectedfrom=MSDN&view=netcore-3.1 example code?
As eyescream's answer explains, there are security issues with the Webserver flow, since any malware listening to that port could also access the security token.
Thus, I want to explain how to use the User-Agent flow in this scenario:
Set REDIRECT_URI to any https-endpoint that you trust. Since your data will never reach that endpoint, it doesn't matter what endpoint you choose.
For example, I use REDIRECT_URI = https:\\login.salesforce.com\, since I am sure that Salesforce themselves will not do anything harmful with a token to their own API, in case something goes wrong and they do actually receive it.
Since you are using a browser (CefSharp) directly in your application, you have access to the URL string. I do not know CefSharp, but I am sure there is something like a BeforeRedirect event which tells you the URL before actually redirecting.
Before every redirect, search the URL string for "access_token=". If you find that string, extract the token from the URL string and close the browser.
Make sure that you close the browser before the redirect. This ensures that the token never reaches the endpoint you chose in step 1.
I looked everywhere for an answer about securing my webApi but always i'm pointed to OAuth or openID, but i don't want the user to login or authenticate. This is my problem:
I have a webapi which is called via Javascript to get the data in Json. This data is used in the Html of that page. (deployed on Azure)
Now i don't want someone else to get that data via Javascript or with a simple GET request. Only my html page is allowed to do so.
I'm looking for something to secure my Webapi to be only consumed by the applications i want. If i look to the OAuth and Azure stuff, people always have to login, but i want this page to be public, but only the webapi needs to be secure.
I can't check on IP, because the call is done at client side in the browser.
It is not possible to authenticate and thus secure the API to be used by a specific client (run entirely in the browser - like SPAs) app. You cannot protect the data the app sends to the API. (see for more details Protecting REST API behind SPA against data thiefs)
You could build some modules server side and then use some token based server to server communication if you do not want to introduce users and end user authentication.
Of course it is also a question of how you interpret security.
If it is just that you do not want other web apps to use the data -
CORS policies will do the job. It is unlikely that there will be more
than some isolated cases of users using a browser other than the
popular once which respect CORS.
If it is you do not want data to be mass downloaded you could
implement some client filtering based on IP. This could even be done
on the networking layer so the API do not need to be modified in any
way.
As a suggestion, you can have it secured making sure the request has some headers defined by you. For example, you can set an Authorization header with a token that only you know. You can for example, create a token based on a key that you and the webapi share, encrypt it with the time you are calling the api. The web api receives the request and:
1 - Check if the request has the token it requires;
2 - if it does, it creates a token the same way your page did;
3 - matches its token with the requests token;
If you are calling the webapi via javascript, the method may be exposed. However, it's one idea
Take a look to CORS (Cross Origin Resource Sharing), it may be your solution.
In synthesis you can allow requests to the Api only from some specific websites. Most, nearly all browsers, support it.
This is how you enable and configure it in Web Api 2.