Question: benefits for social login in comparison to oauth2-rs

[daniel-abramov]

I stumbled across this crate while reading the README of oauth2-rs:

For authentication (e.g., single sign-on or social login) purposes, consider using the openidconnect crate, which is built on top of this one.

I went through the examples and tried using them. I might be wrong, but to me, implementing social login via oauth2-rs seems easier (both in terms of boilerplate and reasoning about it). OpenID connect-rs feels very low-level and barebones, requiring writing a lot of boilerplates (not very ergonomic).

The only two advantages that I was able to spot compared to oauth2-rs are:

• It's easier to get user data (e-mail, name, profile picture) since it's part of the OIDC, whereas in the case of oauth2-rs, a separate API request is required to request the user's information with the access token returned by oauth2.
• It looks like the code for separate platforms might look identical? - I.e. by just changing issuer URL and keeping the rest of the code the same, one could support multiple social platforms at once?

I also noticed that many open PRs add new usage examples, but none have been merged, so I'm not sure about the status of this crate. For instance, I found the google example to be overly complicated and was able to reduce it down to 180 LOC by checking other examples. I thought about submitting it as a PR but noticed that other similar PRs are still open and awaiting review.

[ramosbugs]

Both crates implement the relevant OAuth2 and OpenID Connect standards. The comparison between those standards and their purposes isn't specific to these Rust crates. There are many blog posts that discuss the two, including this short one.

OpenID Connect is intended to be used for authenticating users via an external identity provider (IdP), whereas OAuth2 is intended to be used to delegate access to resources (e.g., your Google Calendar) to a third party. In practice, OAuth2 is often used for authentication, but that's not its original purpose, and more care must be taken to avoid security issues. This is why the README suggests using this crate (when supported by the IdP) for authentication.

OpenID connect-rs feels very low-level and barebones, requiring writing a lot of boilerplates (not very ergonomic).

I'm not sure what you mean by this. The openidconnect crate is built on top of the oauth2 crate and provides additional functionality with a very similar client interface (plus OpenID Connect Discovery for configuring the endpoints, which isn't supported by oauth2). That's a higher-level interface, not a lower one.

I also noticed that many open PRs add new usage examples, but none have been merged

My criteria for adding examples to this crate are roughly the same as for the oauth2 crate. Members of the community sometimes contribute unsolicited examples that don't necessarily illustrate any features of these crates that aren't already exercised by existing examples, and merging those would create an ongoing maintenance burden for me. New examples should illustrate additional functionality of this crate, rather than simply show how to integrate with another IdP. Reviewing and likely closing those PRs hasn't been a high priority for me.

[daniel-abramov]

OpenID Connect is intended to be used for authenticating users via an external identity provider (IdP), whereas OAuth2 is intended to be used to delegate access to resources (e.g., your Google Calendar) to a third party. In practice, OAuth2 is often used for authentication, but that's not its original purpose, and more care must be taken to avoid security issues. This is why the README suggests using this crate (when supported by the IdP) for authentication.

Right, I'm somewhat familiar with OAuth2, but not so much with OIDC unfortunately, but I think my confusion was because I thought that the note in the README meant that openidconnect-rs is a better/easier option for social login implementation, i.e. even more high-level/concise implementation.

I'm not sure what you mean by this. The openidconnect crate is built on top of the oauth2 crate and provides additional functionality with a very similar client interface (plus OpenID Connect Discovery for configuring the endpoints, which isn't supported by oauth2). That's a higher-level interface, not a lower one.

Sorry, I probably poorly worded my explanation What I meant is that using openidconnect-rs instead of oauth2-rs for social login feels more boilerplaty and less ergonomic (even if we just compare the examples for Google in both crates, the one in the oauth2-rs is much more concise and easier to follow IMHO). In short, I think it was just me setting the wrong expectations for openidconnect-rs when I thought that I would be able to implement social login with a couple lines of code for each provider.

Perhaps another crate could be built on top of one of these crates to enable the functionality that I'm talking about, namely, I wish we could have something like this:

let credentials = Credentials {
    client_id: "fADS341324lhxKZV54aofds".into(),
    client_secret: "1324uasdsdf65sdfgzDFewrD".into()
};

let client = Client::new(Provider::Google, &[Claims::Email, Claims::Name, Claims::Picture], credentials)?;

//  Navigate to this URL in the browser to get the code.
let url = client.authentication_url();

// ...

let data = client.exchange_code(received_code).await?;

println!("Email: {}", data.email);
println!("Name: {}", data.name);
println!("Picture: {}", data.picture);