I use Google Webtoolkit together with Phonegap to build a mobile app. My app is communicating over a REST APi with my Backend Server.
What I want to do is a user authentication, i.e., my app user should be able to signup and login. If a user closes the app and reopens it, he should be authenticated again if he has not logged out before.
Usually, with Spring Security you do the authentication on the server by calling the required methods. The client (browser) then contains some cookie information for a persistent login.
1. How can achieve this kind of authentication for my app?
2. Should I do the authentication as for a normal web site with the only difference that the authentication methods are called by the REST api methods?
3. Is there another way of doing the authentication for my mobile app?
I think user authentication for the mobile app will be the same as for a normal web-app.
The Spring backend will create a session once a user is authenticated. By default the user is authenticated for the duration of the specific session (until the user closes the browser/app).
Spring Security has a Remember-me functionality that is typically based on a Cookie approach and allows the user to be re-authenticated automatically..
I don't know if phonegap work with Cookies (see here for some pointers). I guess it depends on the plattform (if webview supports cookies).
May be this will help you I wrote an article that show how to adapt Spring Security to secure REST services.
You can check it in here : http://crazygui.wordpress.com/2014/08/29/secure-rest-services-using-spring-security/
I also posted a working example which shows how I did use that with GWT on GitHub.
Related
I have been using Universal Login with Auth0. I would like to personalise the login experience for my users, so I'm considering switching to an embedded login form and using the SDK to authenticate with my auth0 server.
I only have one application, and potentially a native mobile app in future.
Reading the docs on Cross-Origin authentication it seems to suggest that the main issues here are:
Security risks with sending credentials cross-origin and open up the risk of a phising attack
Some browsers disable 3rd party cookies by default
And it would seem that both of these issues are solved by simply hosting my Auth0 server on the same domain as my embedded login form:
e.g auth.mydomain.com and mydomain.com/login
But still the Auth0 docs strongly advise using their Universal Login, almost every piece of documentation urges it.
My question
Are there any further issues with an embedded login form that sends credentials to an auth0 server on the same domain? When im only developing one application, I have no need for a shared login form.
Are auth0 just encouraging the use of Universal Login for business reasons?
We have an auth infrastructure based on OAuth2 that is integrated into a variety of web apps within our organization. We also have a pure native application with no middle-ware of its own, and we want to integrate authentication into this native application. This application already has its own internal login mechanism with a native login screen, and we don't want to have it start launching external components like web browsers in order to display login windows. We are both the app provider and the auth provider, so the concern of the app having visibility into the user's credentials is less of an issue -- we trust ourselves to not intentionally do anything untoward with the user's credentials, and it's the same people writing a login form in the app as writing it on a web site. :-)
We are trying to figure out how best to support having the application continue to collect credentials the way it does now, but use them to obtain an auth token within our auth framework. With the APIs in place right now, the only way I can see for it to be done is to bake a Client Secret into the native app so that it can use a Resource Owner Password Credentials Grant request, since the code that would normally be making this call doesn't have a server side to live in. This feels really wrong, somehow. :-P
As far as I can see it, many of the structures of OAuth don't really apply to this app because it's not living in the context of a web browser, it doesn't have any concept of a "domain" nor any sort of "cross-domain" restrictions. It has been suggested that perhaps we create middleware for this app just for the purpose of exchanging authentication codes for tokens, but the rationale for that seems to be that this middleware theoretically ought to be able to somehow vet requests to determine whether they are legitimately from the application, and I don't see any way to do that that couldn't be faked by anyone with access to the client application code. Basically, the only purpose such middleware would serve would be to make the Client Secret irrelevant with respect to getting auth codes for credentials.
One thought that came to us was, how does something like Windows do it? Windows very obviously uses a native login form, but then some flow exists whereby the credentials that are entered are used for authentication and presumably, deep in the internals of the OS, for obtaining an auth token. Does anybody know if this architecture is documented anywhere? Does Microsoft's architectural choices here have any relation to OAuth2? What is the "best practice" for an application if you take it as a given that it doesn't have middleware and has its own native login form?
FWIW you don't need a client secret to use ROPC Grant to obtain or refresh tokens if the client is configured as a public client, i.e. a client that isn't capable of storing a secret.
RFC8252 OAuth 2.0 for Native Apps encourages using a native user agent for your scenario, using authorization code flows with PKCE. Authorization services like Okta and Auth0 have jumped onboard too, although they still recommend ROPC if the client is "absolutely trusted".
RFC6819 OAuth 2.0 Security discourages ROPC, but also says "Limit use of resource owner password credential grants to scenarios where the client application and the authorizing service are from the same organization", which are first-party apps.
So while the security verdict seems to be that authorization code+PKCE is the best practice, the UX hurdle of showing a user a browser window to log into a native app seem to be keeping ROPC alive. It's difficult to tell if that UX is jarring because people aren't used to it or because people can't get used to it.
I am creating a mobile application which will talk to my REST Web Services, for login, GET, POST, DELETE and logout. I have been trying to figure out how to secure these REST Web Services using Keycloak. I do not want any In Browser Login on the mobile application, so I was inclined towards Direct Grant API and Admin REST API for authentication and token validations. But, now after looking at the available options on Keycloak, every request from the mobile app must be intercepted, and then make a REST call to the Keycloak module for validating the token and then return a response back to the mobile app.
Is there a better way in doing this? Some inbuilt function calls to check the token validity instead of making an HTTP call for every request from the mobile app? I think this is a huge overhead.
My server is on JBOSS. Spring, Resteasy and Keycloak-services are being used to figure out a solution for this problem.
I am looking to create a WCF (possibly WebApi) web service that sits on top of some of our existing code. Eventually this service will be used by external clients but we are going to start using it with our own mobile app.
As some clients will want to use Gmail and ADFS authentication it seems to make sense to use Azure ACS (this is where our webservices are hosted). However we won't need multiple providers for a while and we will start by using a custom STS that authenticates users against our existing authentication logic.
We already have a rough prototype of the above working using a MVC web application acting as the client.
My problem is how do I integrate this with a mobile application? It looks as if the mobile app will be written using AppCelerator which means I need to authenticate using javascript. We only want users to authenticate to our custom STS so would I need to use Active Authentication? I.e.
Ask user to enter username and password
Directly authenticate with custom STS and retrieve token
Pass STS token to ACS and retrieve ACS token
Pass ACS token to wcf service for each request.
I guess my questions are: am I on the right track and if so how would I achieve this in javascript?
If you want to support mobile devices, it is recommended to provide a web based login interface in your STS. In most cases, a mobile device will navigate to your STS’s sign in page in a web browser. After your STS authenticates the user, it sends claims to ACS. ACS in turn uses JavaScript notification to notify the host application.
You can refer to http://msdn.microsoft.com/en-us/WAZPlatformTrainingCourse_ACSAndWindowsPhone7 for a tutorial about working with ACS in Windows Phone. Similar process can be used for other mobile devices.
Hope this helps.
I think it is possible to issue SAML over Https request. As a starting point Id suggest to look at Thinktecture IdentityServer sources by Dominick Baier. This will help to understand different strategies and how you can use em(there are some goodies for WebApi on Github also):
http://identityserver.codeplex.com/
I am creating an android app that has access to an online Database. The initial app activity screen is a login form where the users credential are validated. If the credentials are valid then the app continues to the next activity. I've looked at OPENID and a few others methods. How would I implement OPENID or a another form of user authentication for my app. I would ultimately like to have a third party take care of user authentication and credential storage.
Have you tried looking at OAuth?
http://oauth.net/
OAuth Signpost is an android implementation of OAuth
http://code.google.com/p/oauth-signpost/
Server side, you need to provide an OAuth ready API, if your server is PHP, take a look at
http://code.google.com/p/oauth-php/