I'm developing an AngularJS app used by third part applications. The third part application and my AngularJS application have a common database where users preferences/credentials are stored. User can login from the third part application and, by redirecting the user into my application, I need to maintain the user logged in, without asking a new authentication procedure.
I can't use cookies because the two applications are in two different domains.
I can't pass a session TOKEN (correspondant to the user logged iin) in query parameters due to man in the middle risks.
Is it possible to make a POST request to an angularJS page? Third part app call my AngularJS login page POSTing a token in the body request. My app take the token, verifyies it and log-in the user.
Constraints:
App in different domains;
Maintain user logged in;
No sharing cookies;
Try to prevent man in the middle;
No query parameters;
HTTPS protocol;
web based applications.
Am I missing something in the https protocols/sharing sessions?
Are there other solutions supported by AngularJS?
How can I redirect the user from one application to another and maintaining the user logged in in a simple way? Is there a simple flow I haven't figured out?
AngularJS is based on REST api communications. I can ask for a webpage (GET the webpage), but I can't make a POST to an AngularJS page. Is there a way to pass/share some values from the first application to my second app in a secure way?
Related
I'm trying to implement Authorization Code Flow for SPA React client with ASP.NET Core and IdentityServer4.
There are two scenarios:
1) User open SPA app, we check if he has an access token and if he hasn't we generate url like
/connect/authorize?
client_id=*client_id*&
redirect_uri=*redirect_uri*&
response_type=code&
response_mode=fragment&
state=*some_state*&
nonce=*some_nonce*&
code_challenge=*code_challenge*&
code_challenge_method=S256&
scope=openid profile email
And so Authorization Code Flow starts. This works pretty clear and after all round trips user comes back to SPA app with code then send request for token (include code and code_verifier) then receive it and with happiness in soul continue using our great application.
2) User opens login page directly and here is where I'm stuck. IdentityServer context knows nothing about this user, code challenges etc. because we didn't make request to /connect/authorize before going to this page as in normal flow. What's next?
I can generate /connect/authorize link directly in login page and do ugly redirect to it and then back to login page (what I don't want to do honestly), but how my SPA app will know what code_verifier I generate here? Of course I can store it in some shared cross-domain cookie, but here should be something better approach I believe.
Another solution I can redirect user from login page to my app, it recognizes that user not authorized and we start scenario #1. Also not my go to approach I think.
What should I do in case user opens my identity server page directly?
Is this possible using Authorization Code Flow or should I consider combine some other flows with this one?
I don't want to use Implicit Flow due to new recommendation from OAuth 2.0 specification.
Quite a simple answer to this - in your second scenario - if your user opens IDP login page directly, they didn't want to go to your app. It's the same if you were using Google or Facebook or one of the other known IDP's for your SPA and as a user I just went to their login page instead. They couldn't possibly know if my intention was to ever come to login so that I am later redirected to your SPA.
Now having said all that - what you could do to make this work somewhat seamless - is to redirect to your SPA's protected page after the user logs in through Identity Server 4 (that's simple because you own the login pages and there is no OAuth involved here). Your SPA would then be triggered to initiate the OAuth2 flow and would redirect back to Identity Server 4. The user has already logged in just seconds ago here though, so the login procedure would be skipped and user would either be presented with consent page or if your client is configured to skip consent page - user would be redirected back to your SPA with the usual tokens and such.
So to break it down into the flow:
User Accesses IDS4 Login Page -> User Enters Credentials -> IDS4
Authenticates User and Redirects to your SPA protected page -> Your
SPA initiates OAuth2 flow and redirects back to IDS4 -> IDS4 displays
consent page -> IDS4 issues auth code back to your SPA.
There is ofcourse extra step here that your SPA will exchange auth code for access token, but I omitted it for clarity purpose as it's not relevant to the question.
I have a request page which every users have access to it but everyone can access to their own requests and can change it with some functions that work with AngularJS.
The thing is that if the user logs out in another page, while the user haven't refreshed this page angular functions are continuing to work.
I know I can Check the loged in user in the controller, but is there any way that angular prevent it?
(I Use ASP.Net Authentication and MVC)
You have to use some sort of communication channel such as signal r or sockets to achieve that. One solution could be to intercept http request and check if the user is login. If isn't navigate to login page.
My context:
An AngularJS application using the Javascript Facebook SDK, and my distinct server (REST APIs).
Workflow:
User is logged in the client through the FB SDK using the method FB.login(callback).
This later gives a short-lived token that is then sent to the server in order to transform it to a long-lived token.
I'm interested in the mechanism of refreshing the long-lived token after 60 days.
So, reading the doc, we found this:
Even the long-lived access token will eventually expire. At any point,
you can generate a new long-lived token by sending the person back to
the login flow used by your web app - note that the person will not
actually need to login again, they have already authorized your app,
so they will immediately redirect back to your app from the login flow
with a refreshed token - how this appears to the person will vary
based on the type of login flow that you are using, for example if you
are using the JavaScript SDK, this will take place in the background,
if you are using a server-side flow, the browser will quickly redirect
to the Login Dialog and then automatically and immediately back to
your app again.
If I interpret it well, when user is ALREADY logged in through FB.login(callback), a simple redirect to the Angular Application's login flow would allow to get a new short-lived token.
I imagine that the FB.login is immediately run anew in this case, without user interaction, as written.
I want to test it simply, so what I've done is:
Logged in into the application through FB.login(callback).
Clicked on a dummy link making a simple redirect with: window.location.replace('/');
My application being a single page application, every URL should be considered as the authentication page.
But the FB.login isn't run in the background, as I expected from the doc.
What would be the reason?
Does it work only when the domain making the redirect is distinct from the client? (I just can't test this case right now)
Did I misinterpret the doc?
My app uses JS Facebook API to use Facebook as a login/pass. Here what happens when you try to login.
User click on the Facebook Login Button
Facebook Authenticates
If Success. I grab the Facebook ID and Name of the user
Calls on my REST API on my APP to check and see if the that FBID is registered in my system.
If Registered, I write the session to verify that the user is authenticated.
This is great since I don't have to store usernames and password. But I am worried that someone will just use a REST API debugger like POSTMAN in chrome and just send a Facebook ID and the name of the user and they will be authenticated.
My question is what is the best way to secure my end that will prevent apps like POSTMAN to just input the fields needed to authenticate? Am I missing something? Can anyone recommend a strategy for this?
Or is using CSRF token the only way to combat this? I am using FuelPHP as a backend and doing a single page app using AngularJS with NgRoutes. But every time I enabled the CSRF on fuel, the token passed does not match what it was in the back-end.
I am under the impression that this is due to that the javascript token function is in the main page, where the ng-view. I know this might have something to do with the ngRoutes.
http://fuelphp.com/docs/classes/security.html
Use Fuel's Auth package. It has Opauth integration which does all the above, and for an entire list of social media platforms, not only facebook.
Always try not to reinvent the wheel, assume someone else has had the same challenge, solved at, and shared the solution with the community.
I m building app who uses oauth2.
I me using:
Laravel for backend
Oauth2 for Laravel (lucadegasperi)
Angular for frontend because it will be also and native mobile app:D.
My question is?
What is the workflow for user sign in?
Now i have.
User comes to site and enter username and password
Angular send post for access token and when access token is returned i go for user data. Then I store access_token in localstorage. I m using grant_type=password i forget to mention.
I have 2 hours when token gona expire. In that moment when token expire I go for new token by refresh_token functionality.
My Questions are:
Is this good way/approach?
What is supposed to happen when user close browser?
Now when user close browser and again enter to my app. I will check localstorage and then autheticate user by access_token. If Access Token is expired i will get new one.
What about remeber me option or so called keep me signed in?
Does it mean thant i must set token that will be expired in 365 days (lifetime)?
or create cookie/ localstorage with access token so when user comes newt time i read cookie/loaclastorage and then authorize user?
And finnaly about destroying token. Now my token will be detroyed when i log of from the app.
Thanks
We are building the same kind of service/app using the same components. We use a password flow and I store the token in local storage if the user ticks the "remember me" checkbox on the login form, otherwise I just store the token in an un-persisted variable that gets destroyed when the user refreshes or closes the browser.
See some notes on testing protected endpoints here:Testing OAuth 2.0 protected API endpoints in Laravel
Marijan!
I'm working on simple app containing two separate layers. 1) Rails 5 Json API provider. 2) Separate NodeJS server running Angular 2 application.
Angular 2 app on Login requests access token from google
Angular 2 app retrieves UserInfo from google/people API
Angular 2 app now able to POST json with User's display name and some id from Google Response json.
Angular 2 POSTs json to my Rails 5 API server (partially implemented, but already works with login/pass auth).
So far I have implemented implicit OAuth2 using the code similar to this Gist. Using this code I am able to get User Identification Info which is enough for me to identify the user in API provider or create account for it.
This approach works for me. Hope it will work for you as well.
Note: this approach might be insecure.