Authorization vs Authentication in Looker

[LookerExperts]

Knowledge Drop

Last tested: Aug 15, 2020
 

In General:

 

At its simplest,  Authentication means confirming your own identity, whereas authorization means being allowed access to a system. In other words:  authentication is the process of verifying oneself, while authorization is the process of verifying what you have access to.

• Authentication: enter some information, which is checked against records and verifies your identity
• Authorization: AFTER your identity is successfully authenticated, your access to certain content is checked (aka the system checks if you are authorized to view certain content)

Source / Additional Reading

In Looker:

In the context of Looker's 'auth' methods, the breakdown is as follows:

1. Authentication methods: 2FA, SAML, username/password (default)
2. Authorization AND Authentication methods: LDAP, OIDC, Google OAuth*

*SAML doesn't explicitly do authorization, though it can have user attributes that looker takes and uses to authorize the user on our end. More about that here

**As we discussed above, authorization happens AFTER authentication, so if you have a system that does primarily authorization (like OAuth systems), it by default also does authentication. However, as far as looker is concerned OAuth methods (G OAuth specifically in this case) only gives authorization, as they don't have to give any authentication information to looker. Rather, looker trusts that G OAuth has done the authentication, and only needs the yea or nay from OAuth to tell it whether to give the user access.

Nearly all of Looker's customer-facing content (web UI and API access) is built primarily on authentication - passing around tokens that represent the user account identity. Looker UI web login cookies and API access_tokens represent a user account, not "permission to do XYZ". Internally, Looker takes the cookie or access_token to look up the user account it represents, then internally tests to see if that user account has permission to perform a particular operation on a particular data object. Looker performs authorization internally based on roles, model access, and permissions granted to the user account.

In other implementations or system designs, the access_token might be decorated with claims or assertions that describe modifications to the permissions associated with the underlying user account identity. In such a system, the access_token would be a hybrid of an identity assertion and an authorization assertion: "this is User X and (with this token) they can edit other users". There is a desire for Looker to evolve towards including authorization information in access_tokens, so that an access_token could be created with fewer permissions than the underlying user account, but this is not currently in active development.

This content is subject to limited support.