I am working on an app for some company, but I have some problems with the security measures in combination with the Azure ADAL library.
For security reasons they setup a ADFS authentication server with the guys of microsoft. So that my webservice can only be accessed by a token given by the authentication server.
I use the adal library to get this authentication token and inside the network I have no problems with accessing the webservice.
For outside the network, I need to go through the proxy, this using a reverse proxy. For authentication on the reverse proxy you also need to authenticate to the ADFS authentication server.
Here is an image to explain it a little bit better :)
For the inside phone
Send authentication request to the adfs authentication server.
Get back a authorization token.
Send a request for data to the webservice with the authentication token
For the outside phone
Send authentication request to the internal adfs authentication server. This needs to pass through the reverse proxy.
The reverse proxy sees that you are not authenticated and will first authenticate with the external adfs authentication server, before he will let you pass through.
This authentication will add a cookie inside the httpclient so that it knows the request is already authenticated.
Now it will request the authentication token, and because it has the cookie inside the request, it will not need to authentication anymore.
It will return the token to the phone.
I am now trying to request some data from the webservice, with the token in the request. But inside the Azure ADAL library I cannot get access to the cookie to add this to the request to pass me through the Reverse Proxy. So the reverse proxy will block me an instead of a data response I will get the login page from the reverse proxy back as an html string.
So the problem that I am trying to address is that I cannot get access to the cookie inside the Azure ADAL library, or is there any other fix I didn't seeing.
Related
I have a web app MyWebApp.
And two APIs: MyAuthAPI and MyServiceAPI, both RESTful NodeJS. MyAuthAPI uses HashiCorp Vault as a token store with OAuth2.
MyServiceAPI has CRUD operations available to authenticated clients.
There is no human login required (or desired) on MyWebApp. Any human can access MyWebApp through a browser and run the service.
At present, this is the (very insecure) flow:
MyWebApp sends clientid and clientsecret to MyAuthAPI to retrieve token. This token is then used for communicating with MyServiceAPI.
The obvious downside is that anyone can capture the clientid and clientsecret by simply looking in developer tools in a web browser. They could then use those to authenticate with MyAuthAPI, generate their own token, and make calls to MyServiceAPI without MyWebApp being involved.
So how do I best secure the entire application so that MyWebApp is safely and robustly authenticated without revealing the credentials?
Thanks.
ETA:
I want to be able to authenticate MyWebApp with MyAuthAPI and then use the generated token to connect to MyServiceAPI. But I don't want it to be possible that anyone can intercept those credentials - currently they can be see in the request header as "Authorization: Basic "
The MyServiceAPI endpoints must be secured so that only authenticated clients are able to access them. But when that client (MyWebApp) is a public website, how do I authenticate without making the credentials visible?
ETA2:
https://mywebapp.com is MyWebApp which is a React application.
https://myauthapi.com hosts MyAuthAPI
https://myserviceapi.com hosts MyServiceAPI
When I load mywebapp.com in a web browser, it authenticates with myauthapi.com/oauth/token to get a token. At present it does this by sending the creds in the header Authorization: Basic
The token that is returned is then saved.
The web application then tries to get the data from an endpoint on MyServiceApi using this token:
Authorization: Bearer
GET https://myserviceapi.com/objects
or POST myserviceapi.com/objects
or GET myserviceapi.com/objects/objectid
or DELETE myserviceapi.com/objects/objectid
MyServiceAPI verifies the token with MyAuthAPI, but that isn't public-facing, so there's no issue there.
The issue is that, as you can see from the attached screenshot of the Developer Tools console in Chrome, anyone using the web application can see the Authorization header containing the credentials, and could then use these credentials to programatically gain access to the auth API to generate a token which can then be used on the service API endpoints.
I want to restrict all access to the API servers to only come from specific applications, such as MyWebApp, on mywebapp.com.
First, I think this question could better be asked in https://softwareengineering.stackexchange.com/.
Second, where MyWebApp is deployed? How it is being used? If it works with https, then the body is encrypted, and when you send the clientId and clientSecret, you should send it in the body, so users will not be able to see them.
Client Credentials Grant should only be used by confidential Clients. Thats because you can't hide the client_secret on non confidential Clients. Your frontend seems to be a non confidential Client.
Normally you should use the Authorization Code Grant with PKCE. But you would need users to authenticate themselves for that.
Feels like you need an architecture design based on standard flows, since OAuth should work like this:
Web app signs user in via an Authorization Server, using Authorization Code Flow (PKCE)
Web app gets tokens from the Authorization Server
Web app calls API with an access token
API validates token using data from the Authorization Server
API then trusts claims in the access token and uses them for authorization
See my Initial HTTP Messages blog post for an example of how this looks.
I have 2 different ways of login into the application
End Customer or External user
Developer or Internal user
End customer or external user will login into the application at enterprise gateway.
This login is common for multiple applications and will use reverse
proxy to load the requested app.
Developers will login into the application using application gateway.
The End user has already authenticated, he would have the access token embedded in the request. How can we validate this access token? The token was generated by the identity server at Enterprise level.
The internal user will be redirected to login page. He would login via Identity server at application level.
Is there a way, I can proxy the Identity server at application level to validate the token generated by the enterprise identity server.
For enterprise user, you could have reverse proxy server to set special header to indicate request is from end user. If reverse proxy sends JWT, your application can introspect it locally. If reverse proxy sends opaque access_token, your application will have to remotely introspect the token.
My client application is a SPA built with REACT-REDUX and back-end API is nodejs with express framework.
Problem is in my client application people can access information without login
so how to authenticate my client application without actually login to my server API.
I tried to use Auth0 but for Single page web application authentication is done only through login, there is an option for machine to machine but that is not suitable to my case because my client app is static web app no server to save client id.
i have studied few articles to get over from this most of them suggest implicit grant is suitable for my case if its true how to implement implicit grant in my client and server.
I have achieved this using JWT
Provide the client a JWT token on successful login which he will have to use in header every time he needs to use API.
then every other request use a middle-ware to verify this token, if valid let him continue or else send auth failed in response
We have a web service, which currently uses Basic Auth over https to authenticate user requests. We also have a website which uses the service, and a native Windows client, which also uses the web service. I've read about OAuth, and it seems like it's always used for giving or getting access to external resources, i.e. delegation, but I'm trying to understand if it's a replacement for Basic Auth.
I'm not quite sure how all the parts fit together. Do you use Basic over https to the website to retrieve a secret and then have the javascript which is making requests to the REST services authenticate to the web service using OAuth instead of Basic?
It seems that at some point the user needs to enter their username and password into a form. I'm not sure what typically happens next. Is this even a use case for OAuth?
If you have local database accounts for the users (Resource owners) then you can replace the basic authentication with the one of OAuth flow named "Resource Owner Password Credentials" flow.
It is very simple flow where you issue HTTP post to an end point specified in your HTTP server usually named /token The content-type for this HTTP Post action is x-www-form-urlencoded, so the post body will contain something like this grant_type=password&username=Taiseer&password=SuperPass
One the request is sent to the /token end point the server will validate the user credentials against your database store, and if all is valid it should generate a token (signed string) which contains all the claims for this resource owner (user). Then your client application should present this token in the Authorization header with each call to any protected end point using bearer scheme.
This token expires after certain period and you can configure this from the AuthZ server. You can read my detailed blog post Token Based Authentication to get more details.
I am writing an API to be used by both my JavaScript app (same domain, API is at api.example.com and site at example.com and 3rd party developers (mobile, desktop, etc). Now I want to use OAuth but I have no idea how the workflow is when using both OAuth and using my application with the same origin policy.
How do I authenticate the user in my web app? When I send the username and password, can I check if the request came from my domain and then return the token? The token will be stored in a cookie and sent back to the server on every request. So there are 2 parts:
If the request came from my domain, just check for token else throw HTTP exception.
If not my domain, do OAuth authentication.
Is this possible? How do I go about setting this up in asp.net web API? (mainly the part about checking if the request is in the same domain)
I am guessing that to log into your web app you're not using OAuth, but simply accept username and password and start a session? If so you don't really have to bother with OAuth for your own site.
Set up the session cookie to be valid across *.example.com and you should be able to validate that cookie both on site.example.com and api.example.com.
Example:
Request comes in to api.example.com/verify_credentials.json
Serve response if OAuth validation is successful.
If not, attempt Cookie validation - serve if successful
Return 402 Unauthorized if both fail.
Here's a thread about sharing a cookie across sub domains: ASP.NET Subdomain Cookie (parent and one subdomain)