Got tips for authentication for in-house web-apps

Discussions
#1

My company (http://pokercopilot.com/) finally has two people…I’m moving some of my custom apps I built for internal management to the web…so we need authentication. I don’t want to do this stuff myself…it is so easy to get wrong…what do you use for authentication your company’s internal web apps?

We use Google Apps for email, and I’m considering using oAuth so that we can use the existing auth credentials we use with Google Apps. Does that make sense for now and for the future, if we grow a bit more?

2 Likes
#2

OAuth seems a mainstream now. I have used oAuth for a (now defunct) SaaS and was able to accept credentials from Google, Facebook, Live and Yahoo with almost no customization per provider.

And it removes the necessity for a user to create and remember the credentials.

So yes, I’d say go for oAuth.

P.S. OpenID used to be the first choice, but oAuth caught up, and OpenID got lost in a sea of incompatible extensions.

1 Like
#3

As you are already invested in Google Apps, OAuth seems like the best choice.

However, if you want to maintain the freedom to (one day) move away from Google, consider Mozilla Persona.

I’ve used Persona for a number of projects, and found it very robust and pleasant in everyday use. It’s easy to integrate, and you can even run your own identity provider service.

2 Likes
#4

Interesting.

Persona though is only an authentication system, i.e. tells you who the user is, while OAuth is originally an authorization system, i.e. tells you what the user can do (rights can be granted by the other users, e.g. “see this picture of mine”). For a richer collaboration scenarios OAuth seems a better choice.

#5

@jacob OAuth is an open standard, and it is widely used. So even if OP moves away from Google Apps they’ll be fine.

What is your backend built with? You can almost certainly find good open source libraries that will give you all sorts of options out of the box. I know Node JS / Express JS has some good ones. I’m sure RoR does too.

#6

Backend is Apache Tomcat + Java Servlets

#7

Hi Steve, In my last client project we used Spring Security with OAuth as the provider. http://projects.spring.io/spring-security-oauth/. It was a Grails app, so wiring the same into a vanilla Java servlet app would be more work :slight_smile: However Spring security gives you all the stuff you’d expect, login, roles, password reset etc. (Not that you would use those aspects if doing OAuth). However note the roles, so you can easily implement not just authentication but authorisation.

#8

I wouldn’t over engineer a authentication solution for two people. Hard code the values and be done with it.

I guess this is a pretty personal decision though, whether its worth the engineering time for just two logins.

1 Like
#9

Good point John…

It’s two people for now. I’m thinking ahead a little. However I think what you said is wise.

#10

Maybe I’m being a bad programmer these days but I always keep picking the easy hack versus the long term play.

I’d rather have the technical debt and work on something customer facing then over-code a solution I don’t need yet you know?

I guess if people were sending me password reset requests every week I’d think differently though but for the most part my hacky solution that took 30 minutes is working just fine. :wink:

1 Like