Use caution with OAuth 2.0 protocol for enterprise logins
Many apps are using the OAuth 2.0 protocol for both authentication and authorization, but technically it's only a specification for delegated authorization, not for authentication.
The reason why authentication specifications, such as the OAuth 2.0 protocol, are such a vital information security control for maintaining secure logins is because it's the first step in the process of authorization, allowing access rights to be granted based on who a user is. Authentication confirms the identity of someone, or something, while authorization occurs after successful authentication; it grants or denies read, write and execute permissions on system resources.
The logic behind many websites and mobile apps, though, makes the mistake of assuming once a user or device has been successfully authenticated and granted the appropriate permissions, then further authorization checks aren't necessary. This can lead to apps exposing data to authenticated but unauthorized requests, negating the benefits of any identity and access management product.
Know what you're getting with OAuth 2.0 protocol
The problem arises from developers assuming that once a user is authenticated, he or she or it can be trusted. Even requests from authenticated users or devices need to be checked to ensure that they are authorized to perform the operation, but many developers fail to include these secondary access control checks. It involves checking the user's permission to view, edit or delete rows and individual fields of the data requested to ensure the user is both authenticated and authorized to do so.
Many apps are using the OAuth 2.0 protocol for both authentication and authorization, but technically it's only a specification for delegated authorization, not for authentication. RFC 6749 section 3.1. states:
The authorization endpoint is used to interact with the resource owner and obtain an authorization grant. The authorization server MUST first verify the identity of the resource owner. The way in which the authorization server authenticates the resource owner (e.g., username and password login, session cookies) is beyond the scope of this specification.
Verification through authentication and authorization
Although there are many libraries and services that use the OAuth 2.0 protocol for authentication, authentication based solely on OAuth is not secure and really needs to be combined with the OpenID Connect standard if developers want to create a secure "social login" that combines both authentication and authorization. OpenID Connect is an identity layer built on top of the OAuth 2.0 protocol, so whereas OAuth 2.0 permits a user of a service to allow a third-party application to access their data hosted in the service without revealing their credentials to the application, OpenID Connect permits a third-party application to obtain a user's identity information, which is managed by a service. This functionality makes it a lot easier for developers to authenticate their users across websites and apps without having to own and manage their passwords. Google+ Sign-In is one platform based on OpenID Connect and OAuth 2.0 that developers can use to provide a secure social login experience for their users.
Whichever authentication and authorization that website and app development teams decide to opt for, it's essential that the associated implementation documentation is read and referred to on a regular basis during development. Although many of these applications and/or policies claim to be simple to deploy, the job of incorporating the code and processes securely is not trivial. Testing should always include both allowed and disallowed misuse and abuse cases, which are unintended and malicious use scenarios of the application. This is the only way to ensure that authentication and authorization controls are performing as expected, and authenticated users and devices can only perform tasks that they're authorized to carry out.
