I have an application developed in Angular JS and Webapi. I have used token based authentication using OWIN Framework. The application is deployed in a Software company and few developers who have knowledge on this techstack, use Chrome developer tool and access the api methods directly and bypass the validations in Client side. Is there a way to control this?
Please find the screen shot of chrome developer tool displaying Bearer token, Webapi method & its payload.
You can't really hide HTTP request showing up on browsers. What you can do is control who gets hold of that access token, its expiry time and what permissions and claims he has.
You can't hide the browser's activities from a user running that browser.
A token should be generated only upon successful login using right credentials and that token showing up on the developer tool can be used to call the API's from tools like the postman until it's expiry(so, set a shorter expiry).
Token A generated using credential of user A should not have the permission to manipulate data of user B and this should be handled explicitly.
So, the one option is that user A can steal his own access token and use it to manipulate only his own data unless the token is alive.
Related
I am adding OIDC login to a WinForms application. I set up the application using the IdentityModel.OidcClient library and pulled the boilerplace code from their WinForm Sample. The OIDC successfully shows the login form, does MFA, and I get back the tokens.
However, if I close the application and open it again, I have to authenticate again. Usually, the SSO session in the browser allows me to bypass this step. It seems the OidcClient is using a browser session that gets destroyed when the application closes and is not shared between applications.
How can I configure my application to use the SystemBrowser or another browser that will maintain those SSO cookies between executions and/or for different applications that use this component.
Thanks in advance.
First thing to check is that the session cookie that you set have an expire date in the future, otherwise it will just be a cookie that will last this browser session.
In your browser you can see that in the developer tools section, like in this example:
Alternatively, you can use a tool like Fiddler to check the response that sets the session cookie and make sure it contains a future expire date.
You can configure that in your ASP.NET application.
I am having difficulty understanding Hybrid flow with mobile application. I am using code id_token Hybrid flow provided by Identity Server 4 in .Net.
Here is my scenario.
All mobile request will go to backend server and backend server will forward request to different APIs on user behalf.
When user first time login
He will be redirected to identity server
A mobile web view will be opened
User will sign in using credentials
identity server will send Id Token and Access Code to Back end
Server
Back end Server will swap Access code for Id Token and Access Token
What token will be returned to mobile application to provide that user is valid. And is it responsibility of Back end server to get new access token without prompting user to re login until user sign out?
Is there any step wrong in above scenario ?
For mobile clients its recommended to use Authorisation code flow along with PKCE. Please read through these two answers to grasp some idea why its suggested Link-1 & Link-2.
Also, RFC8252 provide some best practices application for Native Apps (mobile clients are native apps.!). In that, it recommend not to use web-views.
here is a quote from RFC8252-overview
Previously, it was common for native apps to use embedded user-agents
(commonly implemented with web-views) for OAuth authorization
requests. That approach has many drawbacks, including the host app
being able to copy user credentials and cookies as well as the user
needing to authenticate from scratch in each app
By using web-view, you loose the true essence of OAuth 2.0. You client app get the ability to grasp end user credentials. So use the browser instead of web-view. (Please read more about embedded users agents from this link)
In your architecture, you could enable all of these, PKCE, Authorization code flow and usage of browser instead of web-view. But once the backed receives tokens, it should pass them to your client. That will be a challenge if you stick to this architecture.
But if you can make your mobile application to complete whole flow, you avoid that complexity. Once tokens are received, you may create a connection between backed server by validating tokens. Also, when tokens expire, mobile app will use refresh token to obtain new tokens.
I have a REST API served by Spring boot and I'm using JWT tokens that I generate on my backend server and give the token to the frontend application which is based on AngularJS and HTML5. I want to now control the display of the navigation based on the role of the logged in user.
The question is:
How could the newly logged in user with his token be identified on the frontend as admin so that I can show navigation link A, B and C for example..? Should my AngularJS fronend unpack the token?
When a non Admin user logs in, I can show just navigation links A and B.
How could I do this? Any suggestions?
Should my AngularJS fronend unpack the token?
Yes, if you want to depend on data that is in the token, use it, that is one of the benefits of JWT.
Place an admin or similar claim on your token, and use it. Don't worry about "security", and having an invalid token, because you are using Angular, all your views and logic is easily accessible anyway via developer tools or similar tool, and your "real" security is by checking the token on the server-side anyway.
You can use angular-jwt module for simple JWT handling in AngularJS app.
I'm building a SPA with AngularJS with communication to a Laravel PHP backend. The Authentication method uses JWT, with the tymon/jwt-auth PHP library, which seems to me like a great library.
When user sends his username/password, the service sends back the JWT, which is stored in localStorage on the client. This works fine. However, I want to use a refresh token to continue issuing fresh JWTs to the client, to keep the user logged in as long as he is using the application. Where are these refresh tokens supposed to be issued? Should they be issued when a user sends his username/password? If so, there doesn't seem to be a way in the tymon/jwt-auth library to send the refresh token to the client. Please help, I'm having a lot of trouble conceptualizing how this is supposed to work.
Whether or not you get issued a refresh token when you authenticate with an OAuth 2.0 authorization server depends on which OAuth grant you're using.
When your client is a SPA (an untrusted client), you're probably using the implicit grant and that grant does not support refresh tokens.
Some companies have implemented libraries that are able to refresh access tokens issued by the authorization server using requests in a hidden IFRAME. I'm not familiar with the library you are using.
See also this question for more info.
I'm plan on deploy a Java application to Google AppEngine and use federated login (still experimental according to Google). The application is pretty simple Java EE application which expose RESTful interface for simple CRUD operations.
I then want to be able to authenticate to this application using Windows Client Application written in C#.
I think the application should be able to open a window with a browser in ti which will present the login page of my web application and after successful authentication I should be able to get the login token or a cookie to use in the rest of my HTTP requests.
Is it possible to do such thing using federated login? I've found a post explain how to do it using google proprietary login.
Thank you,
Ido.
I've manage to make this work much easier then I thought it would be.
When I send HTTP request to my web service I get 302 Found response with response header name Location which point to the login page.
I use WebBrowser control, register to it Navigated even and navigate to the URL in the Location header.
When the Navigated even fire I use the code from this answer to get the cookies container.
I check each cookie until I find one with the name ACSID and store it.
For every web request to my service I add cookie name ACSID with the value saved at step 4.
This is not the most secure way of doing this. I will add check for the domain of the cookie but this looks good.