I'm building a web application using Go, and it will be just a bunch of ReST services.
I plan to use AngularJS as the front end, and it will make service calls to the Go application.
I plan to deploy to Google App Engine, and use it's user authentication service.
Is it possible to then limit a user's session to one at a time, so that a user may not share their login with someone else, and then have that that login logged in multiple times concurrently?
Related
We have a situation with our Nativescript Angular App. We use OAuth 2 with PKCE for our authentication process but my team is fairly new to the world of mobile development.
From my research it would seem best practice suggests the lifespan of the refresh token should be anywhere between 2 weeks and 2 months. Currently our access token lifespan is set to 2 minutes and our refresh token lifespan is 30 mins. This means our users have to login every 30 mins using their username and password which isn't ideal for UX and we've received a lot of criticism for it.
Our login page uses a WebView so we considered also trying to auto-populate the form fields with a securely stored version of the username and password but then realised this can't really be done and isn't great for security.
So to improve the login process and make it more seamless, we're looking to setup face/touch ID with a pin code fallback. This means we'll have to push the lifespan of the refresh token to say 2 months or as long as possible — this seems like the best approach moving forward.
That said, the other problem is we also have a website which uses the same authentication server so if we change the Keycloak settings it'll change it also for the website as well which will create more work for the web team.
So my question is should we be using a separate authentication server just for mobile access?
I would suggest you to use offline tokens that never expires. Check this https://www.keycloak.org/docs/latest/server_admin/index.html#_offline-access
Basically in authentication process you pass additional scope named offline_access and instead of regular refresh token auth server returns offline token.
So my question is should we be using a separate authentication server just for mobile access?
If you use separate server (realm) for mobile app then you will have separate user, client and session collections and you will have hard time integrating additional applications with auth server.
I have 3 websites developed upon Angular.js 1.5.8. Now, I would like to connect them to one single sign on web application and manage their authentication from one place. Without using any external libraries or frameworks, how can i achieve this?. For instance, sending credentials from single sign on web application by simple routing at Angular.js seems very difficult. On the other hand, when user logs out from one client, how do the other websites understand that they should logout?
I think you need to spend time on reading OAuth.
https://en.wikipedia.org/wiki/OAuth
Basically it goes like this. Lets say i want to log in to stack overflow and do not want to create an account here . I choose google to provide my identity . when you try to login it goes to google and asks for my account authentication. when i chose allow, google becomes my idenity provider.
Till the time i am active on google, stackoverflow would keep getting up the token. Logout from google means my identity can now not be verified in absence of token !
I'm start building a web application where the user needs to authenticate in order to get access to different modules.
I have been working with ASP.NET MVC in the past and it was quite easy using FormsAuthentication and Server Sessions so I don't have to do roundtrips to the database in order to get the user roles or any other user related data everytime I access a web method.
What I have been reading, AngularJS won't work that way so there won't be any Server Session, etc.. So...
In case I need to verify user identity every time I access a web method do I need to consume database or there is any good practice that I can learn of?
I know there are ways to store state data in client side but how that can affect the performance of a web application?
I have seen that when a user login to an application the best way is to send a Token to the client and then force AngularJS to send that Token everytime a web method is accessed... but what about sending to the client the user sessionId (from database) and then on every web method consumption sending that and then create a filter where you check that the sessionId exists in the database so the user identify is validated?
Appreciate any advice or recommendations.
Thanks.
My take on authentication is that you do not need to bring AngularJS into picture till the user is authenticated. You use simple login page and authenticate user and then redirect him to your app page that has Angularjs. Look at my old answer for more details How to handle authentication in Angular JS application
Let me try to address your concerns.
In case I need to verify user identity every time I access a web
method do I need to consume database or there is any good practice
that I can learn of?
Once you have been authenticated that part is taken care by server and browser cookies, you don't need to do anything. How standard MVC site works.
I know there are ways to store state data in client side but how that
can affect the performance of a web application?
Since AngularJS is a SPA, there is no page refresh. Data stored at $rootScope or using service are there till one refreshes the page. Performance would be better as there are less round trips involved.
I have seen that when a user login to an application the best way is
to send a Token to the client and then force AngularJS to send that
Token everytime a web method is accessed... but what about sending to
the client the user sessionId (from database) and then on every web
method consumption sending that and then create a filter where you
check that the sessionId exists in the database so the user identify
is validated?
This is standard form authentication, and transparent to developer, whatever was required to be done in traditional MVC app for authentication would work here. You don't have to worry about sessionids, tokens etc. To get users identity on the client, you can write a angularjs service with methods such as getUser to get the current logged in user. But i warn you that the authorization related decision should still be done on server.
Applications that run inside the Google App Engine can use Google Accounts for user authentication. I already used this feature and it works great. I just want to know how this is working. Is there a HTTP cookie created? How can an application inside the GAE see that a user is logged in?
The AppEngine SDK takes care of the details for you, but essentially it generates the equivalent of an OAuth request to the Google Account service. All interactions with the login process go through the Google Account service (and thus the cookies it uses for session tracking are not available to the individual app).
We're writing a Desktop application that relies on Google Appengine to authenticate the user and retrieve and store data associated to it.
The way we'd like to authenticate the user is that on launching the application the browser is launched at the login url for our application. Then the user logins there, and then the application makes restful calls without any OAUTH object, but re-using the browser session. I'm questioned that this won't work, since we cannot so transparently use the browser session. Is that correct?
Any alternatives beside authenticating from within the app using the ClientLoginApi?
I'm aware of:
How do you access an authenticated Google App Engine service from a (non-web) python client?
The only way to do this is if you can capture the authentication cookie used by the browser, and send it yourself. Obviously, there's no browser- or platform- independent way to do this.
A better option would be to use OAuth, with OAuth for installed apps to obtain the original token.