Disclaimer : With @loicderoc we work only on OpenId and OAuth since 2016. Despite it is one of the most used protocol over the web, it is the most mysterious. This is exactly why we created please-open.it.
In this document, we will not explain oauth in details, only why you should use it as a user.
Passwords are considered as a nightmare. Everyone has its own strategy :
The last is one of the most secure process you can have. Also, some providers offers you the possibility to log in only with a « magic link » they send at your email address. Slack have this feature, the link has a short life time and contains an identification token.
Using the same password everywhere is the worst thing you can do. You can not verify how the application store passwords, sometimes (we saw it many times), passwords are not encrypted before being stored. Imagine what can happen if someone stole the database… If you are using the same password everywhere, using Facebook or Google as an openid provider will not matter to you ! The big difference is that you store your password only once, in a secured place.
Many passwords reminders exists, with different form factor.
The mooltipass, operates as a usb keyboard. Keep your passwords into the device, locked with a PIN code : https://www.themooltipass.com/
You can find many devices like the mooltipass :
All of them operate like a USB keyboard. Personnaly, I have a bluetooth usb key and keepass on my android phone with a special plugin :
On instructables, many implementations exists with arduino, raspberry pi etc.
Do you know this little card ? You generate a card, print it on a credit card format and keep it on you all time.
How it works ? It’s a reminder. All you have to remind is : a symbol, a color and a length.
IE : for my Google account, I remember « RED, €, 10 ». Take a look at red line, euro symbol and 10 characters. My password is : <WrbmTnVKb
Simple isn’t it ?
Have you seen something like this ?
This lock is known as « cryptex », hackers create similar hardware device as password reminder :
(Thanks Johanna for the picture)
« Example – 'hotmail.com', secret phrase 'ZongGooba': Dial in h o t m on the p@ssTM (ignoring the digits or symbols beside each), then read off the row of symbols BELOW this on each ring. Don't use the row dialed in as Part I of your password; that contains part of the word 'hotmail', which would weaken your password since it's related to the site. Assuming the rows below h o t m on your cylinder now have j% r$ u5 m2 in this position (they might not – each batch of p@ssTM have unique rings) your password for hotmail.com would now be: j%r$u5m2ZongGooba »
Also known as a « 2nd factor », a second hardware device is included in the authentication process. Most of common providers have their own implementation. Let’s take a look at the most common.
One of the first implementation, often use for financial transactions. A server sends you a SMS with a 4 ou 6 digit code you must enter in a form.
By this way, we consider that the phone number is not shared and the phone is personnal. This method is called « OTP » (see below).
Another similar way is used by Google, with a notification on your phone. Google consider that no password is needed with this method.
It is a standard protocol using a USB device as a second authentication factor.
The most common is « yubikey ». You can buy one (or more) keys. Those keys are unique.
It needs an implementation on the server. Google can support those devices :
OTP means « One Time Password ». A single 4 or 6 digits code is generated for a limited time, generally one minute.
There multiple forms factors :
Amazon use some of them for AWS.
IE : on your facebook account, you can activate OTP authentication :
2 methods available :
Use « authentication app ». A code (akka a private key) is generated, and encoded in a QRCode.
Keep this key in a secure place.
WebAuthn is a newly supported authentication protocol, validated on March 2019 by W3C. https://www.w3.org/TR/webauthn/
This specification defines an API enabling the creation and use of strong, attested, scoped, public key-based credentials by web applications, for the purpose of strongly authenticating users. A public key credential is created and stored by an authenticator.
It allows key based authentication, the same we often use for SSH, Git, or... with a ubikey ! Yubico has a great explaination about the protocol : https://www.yubico.com/webauthn/.
Checkout the demo : https://webauthn.org/
In my opinion, this is the end of traditional passwords. All big providers will support this feature soon, this is another big reason of writing this post.
Behind this process, the goal is simple : delegate to another service the authentication process.
A provider : a service that gives authentication to external services or applications.
A user : it’s you ! User as a human (or a machine)
A client (in OpenID protocol) is an application. A developer register his application as a client in an openId provider.
A token : shown as a unreadable flow of characters, it is an encoded authorization.
We know them as a unique protocol, and it’s not !
OpenId ( now named Open Id Connect) is a protocol created in 2005, maintained by the « Open Id Foundation » that « leiminating the need for webmasters to provide their own ad hoc login systems, and allowing users to log into multiple unrelated websites without having to have a separate identity and password for each » ( https://en.wikipedia.org/wiki/OpenID)
Oauth starts later, in 2006 when Blaine Cook was developing the Twitter OpenID implementation. It is an authorization protocol, used for API access delegation. (https://en.wikipedia.org/wiki/Oauth#OpenID_vs._pseudo-authentication_using_Oauth).
If you are a developer, you use Oauth for API access to Twitter, Facebook or Google (or many others).
As a user, you always use OpenID (most of the time OpenID Connect).
As a user, you go to a website and click on « login with ... » button. You will see a redirection to a login form from the provider website.
Take a look in the URL :
There is some strange arguments, such as a « client_id ». Remember, a client is an application registered in the openid provider. This is a first part of the authentication process. Before authenticate the user, there is an authentication of the application.
If you change the client_id in the URL, you’ll get an error message :
Destination (also named « redirect_uri ») : where the provider will redirect you with the token.
You enter your login credentials. Sometimes, you will have a « consent screen » when the client want some personnal informations from your account.
« retreive user infos with token » is not done by all apps.
That is behind the magic. When you click on « login », the authentication process finishes with a redirect to the source application.
The « redirect_uri » can not be changed, It is associated with the client_id.
With this, we can obtain in a single request :
The id_token contains encoded values requested in « scope » :
(those informations are in your browser, decoded with https://jwt.io).
This is how we can show your name, email and profile image on https://login.please-open.it.
Note : there is no personnal information « stolen », you accept to share them in the consent screen on the first login.
As we saw, an id_token contains user informations depending of the scopes requested. An id_token has a limited lifetime, set by the provider.
A refresh_token is a permanent not verified authorization. It is used to get another id_token, without giving your login/password again.
If your authorization is still available, with this refresh_token the server gives another id_token.
Typically, when you log in on a mobile application, the refresh_token is stored in the app. Next time you open it, you get authenticated by this method.
At any moment, the server can revoke a refresh token. It preserves your personnal password from any leak.
This is what you see in the « Where You're Logged In » section in your facebook account security option.
Each entry concerns a refresh token, removing an entry implies a refresh token revocation.
You have the same for your Google Account : https://myaccount.google.com/security
Now, you know how it works, what is transfered to the application. So, as a super internet user, what you need to know and see ?
All providers have a special web console with all authorization and applications you subscribe using your account.
For Google :
then, « Third-party apps with account access »
For Facebook :
For Twitter :
Each provider gives you details about each application you subscribed. You can remove authorizations whenever you want.
Google has 98,000 employees
Microsoft has 131,000 employees
Facebook has 30,000 employees
By thoses figures, you can easily consider that people working on account security and attack prevention will be allways more than in many other companies.
All authentication methods exposed earlier in this document are availbles with those big providers. It increases dramatically the security of your account.
Altough, many people says that passwords are a mess. BTW, they imagine a universal password that feets with all constraints over the web. Despite using the same password everywhere... Use only one account !
Hash algorithms has dramaticaly improve last years. Now we consider SHA256 as a « standard » hashing method.
Keep in mind that most of the time applications you use are not updated with the last libraries and security updates. You should NEVER store personnal informations on those kind of websites.
The right provider you need is the one you often use. Check for each one the authentication methods they offer, choose the most appropriate for you. Be carrefull, sometimes Facebook had some security leaks. If you choose Facebook (or another one), keep in mind that you have to change your password regulary and use at least a second factor authentication method.
All providers are not supported everywhere. You can usually find Google and Facebook. You'll probably need at least 2 accounts.