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.
Related
I have an app which consists of frontend server and a backend server.
front end server connect to corporate OKTA mechanism so that user logins through their corporate ids into my app.
After this step, frontend server connects with some backend work at backkend server (node js). Their it passes in the request body the user id so that we can finally log that the below processing is happening due to user X.
Now suppose user A logs into the app . Now during the APi call to backend server, he can modify the arguments being passed to the api and somehow change the userID.
Is there some way by which backend server validate that userID is not compromised ?
Regards
If your front-end app uses OIDC to log a user in, then you should be able to get back an id_token, which has user identity in it. You can pass this token to your back end app for API calls. This approach is not ideal though, as your backend will still have issues with trust, as it does not know if the token presented by the front-end app is a legitimate one and not stolen.
Other way is to harness traditional authorization_code flow (again, assuming you can do OIDC with you company's identity provider). There your back-end would retrieve the tokens for you directly from authorization server and can get a user's identity from it. Based on that it can then create a session and embed user info into it. It's a bullet proof approach lacking trust issues from above.
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
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.
I have a custom OAuth 2.0 authentication server deployed alongside my secured API. I also have a single page application delivered as static content by an nginx deployment. I'm now confronted with the issue of how to authenticate users of this SPA without an active backend through which to proxy a password grant -- I obviously cannot embed the client secret in the SPA.
What solutions exist for such an issue?
I have discovered that the resource owner password credentials grant may be just what I'm looking for. By using this, I would be able to send username and password credentials directly from my trusted SPA using an established client ID. If I restrict this grant to only be valid for this particular client and validate the origin of the request, I can see this being a reasonable compromise.
My question then becomes, how do I create this client and the requisite associated user? Does that not imply that there is some special user account in my system with this associated privileged client? OAuth 2.0 seems to imply that clients must be associated with a user of some kind. Do I seed these special user and client objects when my application is deployed? Is that secure?
I think the implicit flow could be used just fine.
User is redirected from the SPA to the OAuth2 server
User authenticity is verified
User is redirected back to the SPA along with tokens
For the server-side API, you need to decide whether you want to use access tokens or ID tokens (OpenID Connect - OAuth2 extension).
If user's permissions for the API are stored at the OAuth2 server, the SPA may ask a user for some of the permission that will be included in the access token. This is a permission delegation and it can be handy if there are more application each requiring different permissions.
If the OAuth2 server doesn't hold the permissions and the API manages them itself, it's probably more suitable to use ID tokens, because they represent identity of the caller and can be verified without accessing the OAuth2 server on every access.
The API probably doesn't need to have its client_id, since it just accepts tokens - it doesn't request them - it checks that access tokens contain permissions for actions users invoke or validates ID tokens.
The SPA needs to have its client_id with registered redirect_uri-s. No client secret needed, since SPA-s cannot keep them safe. It has to be deployed using HTTPS to secure the transferred tokens.
I am looking at the following example for the implicit grant.
http://code.msdn.microsoft.com/OWIN-OAuth-20-Authorization-ba2b8783
I can see how the example is redirecting unauthenticated user to the same authorization serer's log in page. which is something like follows:
Client ---> AuthServer ---> 401
|
<--- Login (UI) <------
(On Auth server)
My problem is that I dont want to authorization server to handle UI part of login page. That is my authorization server is a web api and its only job is to process the owin pipeline and authenticate user via webapi.
So ideally what I would like to do is, that authorization server respond with 401 to the client. Client (could pure js app) show login page (username/password) and POST to authorization server with username/password over SSL and auth. server says you are ok to login.
This will give all the client to manage Look and feel of their login page but the authentication (logic) part is done via auth server webapi.
Is this possible?
Are there any security implication that I need to be aware of when implementing this (only specific to this scenario) ?
Thanks
If the implementation of the authorization server supports "Resource Owner Password Credentials Grant" and allows your application to use it, you can implement your scenario. However, it is unlikely that the authorization server does.
The primary purpose of OAuth 2.0 is to allow third-party applications (like your application) to access protected resources of end users (= resource owners) without passing end users' credentials (username/password) to the third-party applications. So, your scenario is the very use case that OAuth 2.0 tries to avoid.
[Comment to your additional question]
If you are an implementor of an authorization server, yes, you can implement both "Implicit Grant" and "Resource Owner Password Credentials Grant". It's up to you. On the other hand, if you are an implementor of a client application which accesses an authorization server that has been implemented by someone else (at least not by you), whether your client application can use "Resource Owner Password Credentials Grant" depends on the implementation of the authorization server. What I meant was that in general authorization server implementations would not give a chance for third-party applications to use "Resource Owner Password Credentials Grant", because it's a kind of the last resort and the specification (RFC 6749) says "The authorization server should take special care when enabling this grant type and only allow it when other flows are not viable."