Complications Of Openid Consite Authentication Protocolss

1871 Words 8 Pages
When OpenID was first created and starting to be used by major companies as their go-to single sign-on solution, people were skeptical. Today, it is used just about everywhere and people do not usually think twice before using it to log into their favorite website. We will explore how the improvements OpenID has made over the years have caused it along with OAuth to become some of the most widely used cross-site authentication protocols. In this paper, we will also touch on what flaws still exist in these protocols and if their benefits outweigh those flaws.

This work is relevant because OpenID Connect and OAuth are used so widely today, both internally for companies and for public-facing websites. The security implications that stem from
…show more content…
OpenID 2.0 is being deprecated by most identity providers now, with most of them switching to pure OAuth 2.0 or OpenID Connect. OpenID 2.0 is an authentication protocol that websites allow the end-users to use to authenticate with their site. The website will usually have an option to specify an OpenID URL to authenticate with and then that site will request an HTML document from the identity server. The OpenID server returns that document and uses the headers to construct various information including what to return in the event of a successful login. The user is then presented with a login screen from the OpenID server and when successfully authenticated, the OpenID server will ask if the user trusts the original site they are authenticating to. Depending on if the login was successful or not, it will redirect the user to the success or failure URL which will be on the original website. If they are redirected to the success URL, they are authenticated to the …show more content…
Before I explain OpenID Connect, let us go over the flow for OAuth 2.0. A site, let us call it NewHipSite, has OAuth 2.0 configured to authenticate with an external site which we will call AuthProvider. When the user accesses NewHipSite, there will be a button that says something along the lines of “Log in with AuthProvider”. The user then gets redirected to the login page for AuthProvider with some extra information including a “response_type”, a “client_id”, and a “redirect_uri” in the query string put there by NewHipSite. The “response_type” is what kind of response NewHipSite wants AuthProvider to give them, the “client_id” identifies NewHipSite, and “redirect_uri” is the URL that AuthProvider will redirect the client once successfully authenticated. At this point, the user is now on AuthProvider’s site and will either automatically get forwarded to the “redirect_uri” if they are already logged in, simply have to log in and get forwarded, or (ideally) have to grant explicit permission to allow NewHipSite to get access to whatever information they are requesting from AuthProvider about

Related Documents