Apache Authentication using OpenID Connect and Google Apps – an Overview
Why authenticate using Google Apps (or another OpenID Connect provider)?
Using Google Apps or another OpenID Connect provider for an authentication will:
- allow you to use individual usernames/passwords instead of shared usernames/passwords
- reduce the number of usernames/passwords that users must remember (see “password fatigue“). Users will instead be logged in automatically using their Google Account
- improve security through the use of Multi-Factor Authentication if you have enabled Multi-Factor Authentication for Google Accounts
- reduce the administrative support burden on Ops/IT staff through centralizing administration of users
Why use Apache authentication and authorization instead of application-based authentication?
Using Apache authentication and authorization instead of application-based authentication will provide two benefits:
- eliminate the need for implementing an authentication and authorization method within each application – instead you define protected URLs within Apache directives
- management of usernames/passwords outside of code
Why to avoid Apache authentication with OpenID Connect?
- complexity – Open ID Connect and Oauth 2.0 can be complex, particularly when compared to file or database authentication and authorization
- evolving standard – although I have not encountered this, I do know that different OpenID Connect providers implement parameters and access expiration differently
- reliance on third parties – in this case, your application will rely on the availability of Google’s APIs for user authentication and authorization, as compared to a file or database
- time to implement – you should estimate a half day of effort for implementation and testing of Apache and OpenID Connect. Add an additional half-day of effort for understanding Oauth 2.0 (which OpenID Connect relies on) if you haven’t worked with the Oauth 2.0 before.