Broken Authentication Methods & Questions

[mooyoul]

Hello there,
I've been playing around DeviceHub - Great so far! Thanks for efforts to maintain this.

Anyway, I had some issues around Authentication methods:

1. SAML: Completely Broken

• Importing passport and passport-saml package is invalid. Needed to switch to default import (e.g. import passport form "passport")
• After successful authentication, I noticed authentication check is moved to client-side. some authentication methods such as mock-auth or ldap set authentication credential to local storage by rendering react app. but some authentication methods such as SAML, OAuth2 were not.
• I have fixed those issues and will submit a PR.
• Question: Do you want to keep/maintain SAML Auth?

2. OpenID: Partially Broken

• I had a issue with Okta IdP.
• Okta does not have user_info scope, they use profile scope for getting user profile instead. There's a scopes option, but there are no usages to modify requested scope. So modified code to respect scopes option to resolve this.
• Okta requires state parameter, and validation must be performed. So modified code to generate state parameter, store this to cookie (although this is bad security practice), then perform validation to continue auth flow.
• Currently OpenID Auth implementation does not use session. To be honest, Storing nonce/state value to cookie is not good idea due to security reasons. We need to utilize session for storing those values.
• I think that OAuth2 Auth implementation and OpenID Auth implementation overlap in some areas. However, OAuth2 implementation does not appear to be maintained.
• Question 1: Which OpenID implementation (or IdP) are you using?
• Question 2: How should we organize OAuth2 authentication and OpenID authentication?
• Question 3: How can we improve OpenID authentication?

[DaniilSmirnov]

Hi! as for SAML, the answer to the first question is yes, we want to keep and support SAML authentication if anyone uses it.
Also, We would be very grateful for PR with fixes

[irdkwmnsb]

Yeah, different openid providers often put user data in their own special fields, and when implementing support with our own auth provider that follows keycloak's openid connect scheme - we didn't come up with a universal solution, so decided to not spend more time on it since there was plenty other of work to do. Creating a session is a valid option, but we want to make every component of the app scalable, so the units should be stateless. That leaves us with an option where we use an encrypted session cookie, and store the nonce and state there.
IIRC OAuth2 and OpenID as an auth scheme are completely different in the way they work, so I'm not sure how one would implement an auth provider that's compatible with both. And even so, we want to allow for multiple auth providers of same type - for example multiple OpenID SSOs inside one company.
As to how to improve - we will be very grateful if you can fix the issue for yourself and send a PR that would fix it for other users.