#oauth2.0

At System76, we pride ourselves on making computers by nerds, for nerds. Our dedicated group of engineers work hard to create the best solutions for like-minded professionals, including on our website.

Today, we’re happy to announce new security updates for all system76.com accounts in the form of Recognizer, our open source authenticator service. The most notable changes this tool brings are the introduction of two-factor authentication and an upgrade in password hashing to further protect your login credentials. These updates, releasing this Thursday (February 11th 2021), will substantially increase security and make our site more flexible as we grow. Once the update is released, all users will be required to reset their password.

Two-Factor Authentication

Setting up two-factor authentication protects your account in the event that someone gets ahold of your login credentials. Beginning Thursday, February 11th, you can turn on 2FA by signing in to your system76.com account. From there, go to the Account Details page, where you’ll find the Two-Factor Authentication section. Follow the instructions to link your account with your third-party authentication app, such as Google Authenticator or 1Password.

Under the hood, System76 uses the Erlang ‘pot’ library, which generates RFC 6238 time based one-time tokens compatible with these third-party apps. Our authentication system also uses OAuth2.0 and JSON Web Token (JWT), two secure industry standards for authorization flows and communication between systems. The use of OAuth2.0 opens up the door for the potential to sign in with a third party, or even Pop!_OS, using a “Log In with System76” button; though for now, it’s only being used with System76 projects.

Password Hashing

Another piece within Recognizer is the migration to Argon2 password hashing. In addition to sounding delicious, password hashing is a secure way to store passwords for when you want to access your account at login. Passwords are transformed into a long string of characters that cannot be converted back to your actual password. A “salt” is added for further security, which adds a random set of characters to your password hash. This ensures your password is linked solely to your account, even in the event that another account uses the same password as you. Lastly, we increased our password requirements to include a minimum character length, special characters, capital letters, and numbers.

While your passwords have always been stored safely, we’re taking this opportunity to move to a newer and stronger algorithm. We chose Argon2 for its modern hashing technique and resilience to new attack methods. It also has a standard format for storing the hash, salt, and parameters as a single string, making it easy to change hashing options in the future without having to force a password reset. However, because existing passwords are currently hashed using an alternative algorithm, all existing users will need to reset their passwords to migrate their accounts over to this new algorithm on Thursday, February 11th.

Open Source Security Measures

System76 has always led by example with open source solutions. So far, we’ve open sourced our Protobuf messages, our notification microservice, and our Zendesk integration. The newest addition, Recognizer, is written in Elixir, styled in Bulma, and released under a GPLv3 license.

Overview

This article is for the one's who is already working with PHP/Laravel or who wants to quick start developing RESTful API with OAuth2.0 security using Laravel 5.5 Lumen 5.5.

Here I'm sharing the Live demo and Source code of a RESTful API with OAuth2 authentication/security developed using Laravel Lumen 5.5.0. You can use this if you want to quick start developing your own custom RESTful API by skipping 95% of your scratch works. Hopefully this will save lot of your time as this API includes all the basic stuffs you need to get started.

Developer Dashboard

This API also includes a developer dashboard with the API documentation which is developed in Laravel 5.5. This will be useful to manage your developers access to the API documentation.

Why Laravel Lumen?

In short, It’s fast, light, and easy!. Lumen eliminates all the unnecessary and heavy features in Laravel and load only components like Eloquent, middleware, authentication & authorization, …etc which keeps it light and fast. Lumen focuses on building Stateless APIs​. Therefore, sessions and views are no longer included in the latest version of Lumen.

What is a RESTful API?

REST is an architectural style for building APIs. It stands for “Representational State Transfer”. It means when we build an API, we build it in a way that HTTP methods and URIs mean something, and the API has to respond in a way that’s expected.

Something about OAuth 2.0

The OAuth 2.0 is an authorization framework which enables a third-party application to obtain limited access to an HTTP service.

DEMO

http://laravel-lumen-rest.dockerboxes.us Login: developer/developer

Source Code

https://github.com/sirinibin/laravel-5.5-lumen-5.5-with-OAuth2

Official Documentation

Documentation for this RESTful API can be found on the Lumen RESTful API with OAuth2 Documenation.

Security Vulnerabilities

If you discover a security vulnerability within this API, please send an e-mail to Sirin k at [email protected]. All security vulnerabilities will be promptly addressed.

Installation instructions

https://github.com/sirinibin/laravel-5.5-lumen-5.5-with-OAuth2

Beware of links that ask you to log in through Facebook. The OAuth 2.0 and OpenID modules are vulnerable.

Serious security flaw in OAuth, OpenID discovered

Attackers can use the "Covert Redirect" vulnerability in both open-source log-in systems to steal your data and redirect you to unsafe sites.

Following in the steps of the OpenSSL vulnerability Heartbleed, another major flaw has been found in popular open-source security software. This time, the holes have been found in the log-in tools OAuth and OpenID, used by many websites and tech titans including Google, Facebook, Microsoft, and LinkedIn, among others.

Wang Jing, a Ph.D. student at the Nanyang Technological University in Singapore, discovered that the serious vulnerability "Covert Redirect" flaw can masquerade as a log-in popup based on an affected site's domain. Covert Redirect is based on a well-known exploit parameter.

For example, someone clicking on a malicious phishing link will get a popup window in Facebook, asking them to authorize the app. Instead of using a fake domain name that's similar to trick users, the Covert Redirect flaw uses the real site address for authentication.

If a user chooses to authorize the log in, personal data (depending on what is being asked for) will be released to the attacker instead of to the legitimate website. This can range from email addresses, birth dates, contact lists, and possibly even control of the account.

Regardless of whether the victim chooses to authorize the app, he or she will then get redirected to a website of the attacker's choice, which could potentially further compromise the victim.

Wang says he has already contacted Facebook and has reported the flaw, but was told that the company "understood the risks associated with OAuth 2.0," and that "short of forcing every single application on the platform to use a whitelist," fixing this bug was "something that can't be accomplished in the short term."

Facebook isn't the only site affected. Wang says he has reported this to Google, LinkedIn, and Microsoft, which gave him various responses on how they would handle the matter.

The following is a guest post by Manuel Neuhauser and originally appeared on his blog. Manuel is currently in the Ruby-003 class at The Flatiron School. You can follow him on Twitter here.

OAuth 2.0 is an authorization framework that allows applications to gain access to an HTTP service. It has become the de facto standard for users to share data from one website account with another website. You may have already used OAuth without even realizing it. The popular login options “Login with Facebook” and “Login with Twitter” are both utilizing the OAuth authorization process defined in RFC6749 — namely OAuth 2.0.

When building a web application, OAuth is making it easy for developers to tie in with other websites, though there are some terms that first need to be understood to comprehend exactly how access can be gained and granted.

Authentication is the process in which one user identifies herself based on some shared secret like a username and password or a token. Authorization, on the other hand, dictates the level of access an authenticated user has to any given resource. A token or hash (not to be confused with the Hash data-type) is merely a generated, hard-to-guess string of characters.

Token-based authorization such as OAuth has the advantage of eliminating the need for a user to share her password with a 3rd party app, allowing the user to restrict the level of access, and permitting the user to revoke access to her data.

In order to ensure security without compromising the ease of use, OAuth 2.0 requires that all communication is sent over an SSL connection.

Let’s look at a concrete example of how we can use OAuth to gain access to a users GitHub account within our app.

  1. Register the application

First and foremost, we need to establish a trust relationship between our application MyAppand Github. This is done through means of using a shared client ID and client secret which is generated when registering our app with Github. When using these credentials in API requests, Github can properly identify the authenticity of our app.

  2. Authorization request & grant

In order to initiate a request to gain access to certain data in the user’s Github account, we craft a special link in our application MyApp which, when clicked, will forward the user to GitHub with an authorization request. It looks like this:

When looking closer at the link, we see three parameters:

client_id – This is the secret shared identifier that Github has previously provided to us when we registered our app.

scope – It describes what resources our app wants access to. The available scopes are defined by Github.

redirect_uri – Tells Github where to send the authorization grant to.

Github will use these parameters to validate the authenticity of the request and find out what resources is requested. It presents a prompt to the logged in Github user asking whetherMyApp should be allowed to access a certain set of resources in their account. When the user agrees to grant access, Github will send an HTTP GET request to the redirect_uri and appends a code parameter with contains the authorization grant.

3. Access Token

Now that MyApp has the authorization grant, it can contact Github and request an access token, which is used for the actual API calls. To do that MyApp sends a POST request to Github including the client ID, client secret and the authorization grant code.

If Github’s authorization server receives valid credentials, it will respond with an access token. This access token allows MyApp to send API requests on behalf of the user for resources belonging to the previously defined scope.

4. Making API calls

At this point, MyApp can make API calls to retrieve information from the Github user account, and it is authorized with the access token. The access token can be put into either the header:

… or alternatively, added as a parameter to the API call URI:

Additional information

Note to self - Next time your FB tokens get invalidated like in a password change case to regenerate the access_token for posting as a page do the following.

Obtain a page access token as quoted here 

Go into graph explorer select the app and get access tokens with manage_pages permission

GET me/accounts which gives the page access_token

Now this token is a short lived token, to get a token which does not expire exchange the original token in step 2 for a long lived token and then regenerate step 3 with the newly obtained token as detailed here

To get a long lived token curl https://graph.facebook.com/oauth/access_token?grant_type=fb_exchange_token&fb_exchange_token={token_from_step_2}&client_id={app_client_id}&client_secret={app_secret}

responds with 200 OK text/plain access_token={long_lived_token}

Hello there, This is Prach (プラッチです!). I would like to change my writing language to English. Hope you can understand me. 

I have introduced about Rakuten's OAuth API and its mechanism behind it last time. Would not it be great the we can apply that to our application? So, I came up with the idea to integrate Rakuten APIs with your mobile phone applications.

This diagram shows how a mobile application is integrateed with Ads from Rakuten Affiliate Motion Widget, and how to link it with user's Rakuten Favorite Bookmark. It might generates revenue from your application via our advertisement. 

1) On the upper left, you can integrate your application with Ads from Rakuten Affiliate Motion Widget (please check this link)

2) When a user click on the Ads, the application navigate to the next page, to display more items.

3) Users may add their product found on the page using Rakuten Favorite Bookmark API (please check this link)

4) Rakuten Favorite Bookmark API requires an authentication via Rakuten OAuth API.

5) If the authentication was okay, the item of interest will be add to user's bookmark list, and then navigate back to the main application.

You may provide some link directly to the shopping page, so that you are able to acquire Rakuten Affiliate points in the case the item is purchased.