I am using UserService to allow my users to register and login.
We find that users for some reason would like to create a login on our own site without using their existing credentials.
I know UserService supports Google Friend Authentication and we can use Yahoo & other openids. However, I would like to know if we can add our authentication mechanism without becoming implementing as an open-id provider/producer.
If becoming a openid provider is only viable option, are there any recommended libraries for AppEngine.
Thanks.
How you do this depends entirely on how you've built your authorization system. Using the Users API directly, your only options are to use OpenID or Google Accounts (and only one per app, at any one time, not both). If you want more flexibility, you will need to build your own authorization subsystem, or use an existing one, which abstracts away different auth providers. See, for instance, webapp2's auth module.
Related
I did dome research about WSO2 OIDC but what I found is rather than use my own login page I can only just customize the login page only
Is there any method to use my froundend page to let me have the full control of the layout
Contrary to what you have mentioned, you can actually modify the layout of the SSO page by tinkering with these two files:
https://github.com/wso2/identity-apps/blob/master/apps/authentication-portal/src/main/webapp/login.jsp
https://github.com/wso2/identity-apps/blob/master/apps/authentication-portal/src/main/webapp/basicauth.jsp
However, if you still insist on using your React app, you can use the password grant to build your own React-based login page. But there are several caveats:
You cannot use multi-factor authentication or social media login since the user is not going to be redirected to the identity server during the authentication process.
It should only be used with first-party applications that you trust.
It compromises the security of your application and it is not recommended to be used by OAuth 2.0
Personally, I would not want to use this grant but I wanted to let you know this option exists if you insist on handling authentication yourself.
Authentication endpoint (login portal) is tightly bound to Servlet technologies as of the latest release. You can find how to host it external on any servlet container (e.g. Tomcat) here
There is an improvements suggested to allow it to developed using any technology including ReactJs, exposing API set for authentication flow. However this has not been prioritised yet.
Hence you can use the existing Servlet/JSP way for your research. This may seem bit harder than using ReactJS, yet is the best way available at present.
I have a public-facing application that uses ASP.NET Core Identity to store first-party logins, and no intention of using third-party IdPs like Facebook or Google. I want to build the front-end in React, and the application comprises an API fronting a couple of back-end services to which I'll need to forward JWTs for authorisation.
The plan so far is to use Identity Server 4 as the IdP for the project, backing it into the ASP.NET Core Identity data stores.
Current guidance is to use Authorization Code Flow with PKCE, which would require redirection to the IdP, two sets of styling etc.
In this scenario, where there is no possibility of a third-party IdP, is Resource Owner Password Grant still highly discouraged? On the face of it, it gives a neater experience:
User populates React-based login page
XHR POST to IdP with credentials (modulo an MFA challenge)
IdP returns an access token, React app subsequently uses that for future requests to the API
What issues will I introduce by pursuing the ROPC grant in this specific situation, vs accepting the need and duplication involved in a redirect-based flow to the IdP?
AMOUNT OF WORK
This is one of the big issues. As well as a login screen you'll have to make sure other areas such as Forget Password also work. If you build a second app you'll need to make it work there also.
EXTENSIBILITY
This article summarises problem areas. One of these is no scope to ever extend login solutions.
SECURITY
Token refresh does not (usually) work with ROPG, which leads to long lived access tokens and other complexity. Also, with OAuth it is recommended that the app never sees credentials.
From a security viewpoint it looks more modern to redirect the user - all the big providers do it - eg Google, Microsoft.
BRIDGING SOLUTION
As you say, if the password is private to your app it may not be the worst thing in the world. Capturing a user's Google password in your app would be a bad thing though.
ROPG has its uses but does not have much of a future - it is deprecated in OAuth 2.1 and providers will be getting rid of it. So I would also recommend what LalitaCode suggests ..
You can create a React based Identity Server login page for Authorization Code flow with PKCE instead of using MVC UI if you want. It is just extra work and complicated. I would recommend you just style the Identity Server MVC UI to look exactly like your frontend SPA. This is the simplest way and the path I took when I did a project with Identity Server(with Angular as front end).
I recently got started with Google App Engine. I intend to use Flask to serve web pages and the Endpoints API, preferably with the Endpoints-Proto-Datastore for everything else.
From the beginning, non-Google Authentication mechanisms on GAE seem like they need some work. I'd appreciate any light shed on issues I've found so far:
Custom Authentication
If you can write an Open ID provider as part of the app, use something like Python-OpenID and also implement a consumer in the same workflow so it appears like regular login. This way it integrates nicely into what the GAE Users API provides.
I'm guessing if this is done right, users.get_current_user() will work just fine.
If you want to skip writing your own OpenID provider and instead write an email/password auth system using Flask-Login integrating with NDB, that should be alright too. However, one puzzling bit of info in the GAE documentation says I can instantiate a user object like so:
user = users.User("XYZ#XYZ.com")
However, (there is no user.put() method here) a users.get_current_user() still returns None. So what would the use of constructing the user object ever be?
Endpoints Authorization
On including a user=required in the method decorator for an Endpoint-Proto-Datastore rolled API, OAuth seems to work right away - all you have to do while testing it in the APIs explorer is to turn on the OAuth 2.0 switch and pick a valid Oauth 2.0 Scope. So does that mean that if we implement a OpenID provider that integrates with the Users API correctly, it won't be sufficient to use the OAuth magic of Endpoints API?
Here too, it seems like constructing a user object will not help satisfy the authentication requirement.
How would custom authentication / another OpenID implementation work with Endpoint API authentication/authorization?
I wanted to not use oAuth, but a simpler form of Authentication with user/token.
So what I've done is create a custom ServletFilter that maps to /_ah/spi/* and intercepts login information from the HTTPServletRequest there, if it is an Endpoint-API-Request.
Seems to work thus far, but am not really sure if that is the way to go. But as I've found no examples for non-oAuth-Auth anywhere, that's currently my best shot.
Would love to get some best practice hints from #bossylobster or #Dan Holevoet.
Currently have an client application running on GAE that supports OpenId login to access resources on a server application (also on GAE) through OAuth. All is fine.
But, it requires that the user have an account with Google, Yahoo, or other OpenId provider. While that seems fine for personal users, how do I handle the corporate case where users want to use myname#mycompany.com as their login?
Do I build my own OpenId provider, host it, and store those names/passwords in a database?
Is there existing OpenId source that I can use, but give it my own names/passwords?
Do I skip OpenId entirely and somehow get my own custom db lookup to integrate with GAE authentication?
Something complete different?
My work is in Java, so Java solutions are preferred. And since this is more for prototyping than for production use, easier solutions are preferred :).
After doing some additional research it seems that if I want to stick with my current use of Restlet's GAEAuthenticator then I will have to rely on OpenId. There appears to be ways to rewrite the entire authentication so that it works both with Google/OpenId and a custom database (not what I want to try), and there appear to be commercial products (SadaSystems) that seem to also do it.
For now, my workaround is to ask people who want to use their own email address in our system to sign up with MyOpenId and add that email address as their persona.
I have created a logout url with the users api: https://developers.google.com/appengine/docs/go/users/overview
But I only want it to disconnect them from my app, not log them out of their other Google services (Gmail etc). Is that possible?
You can't do this directly with the users API but see this question for alternative options:
Instead of using the UserService API to logout, you can manually remove the AppEngine specific cookies that are set. Check out this blog post that discusses how to so (written in Python, but you should be able to modify it for Java). This should effectively log the user out from your own app but not from other Google services (though I haven't tested this myself).
The more robust approach would be to create your own User class and manage your own session cookies, while wrapping the UserService API. The downside of this approach is the extra work that is required to set it up, compared to the very easy to use UserService API. However, the advantage of maintaining your own Users is that you will be able to use other methods of authentication besides for Google (e.g. now you will be able to use a Facebook login as well, or even a native login if you choose to set that up).