[sda-auth] OIDC login does not work over http

[mrtamm]

Describe the bug

OIDC login fails when SDA deployment is working over non-https protocol.

Steps to reproduce

Assuming there is no TLS certificate (no values for server.cert and server.key) configured for sda-auth:

1. Open the login page (e.g. http://localhost:8080/)
2. Click on "LS LOGIN" under "Login with credentials"
3. Perform login at the configured OIDC Identity Provider
4. When redirected back to the sda-auth service, this message is shown: Authentication failed. You may need to clear your session cookies and try again.

The error message is misleading because sda-auth actually set the state cookie before redirecting to the OIDC Identity Provider but the browser discards it as it has the Secure property set, which means that the cookie can be accepted only if it came over an HTTPS connection.

Expected behavior

• sda-auth does not set the Secure property for the state cookie when the redirect URL does not have https:// as prefix.
• sda-auth sets the Secure property for the state cookie when the redirect URL has https:// as prefix (retain existing desired behaviour).
• OIDC-based login to sda-auth over http (non-secure) protocol is possible.
• Tests verifying the fix are added

Additional context

This is where the state cookie is declared with the Secure property:

sensitive-data-archive/sda/cmd/auth/main.go

Line 223 in b5adfd1

ctx.SetCookie(&http.Cookie{Name: "state", Value: state.String(), Secure: true})

It could use the redirect URI to check if the destination URL has https:// prefix before setting the Secure property to true.

In contrast, sda-api configuration supports the scenario where cookies might work over non-https connection: api.session.secure property. However, I think sda-auth does not need an extra configuration property for this, as the redirect URI should be sufficient to determine whether Secure cookies are supported.

Estimation of size: small

Estimation of priority: medium

(It is not critical as production environments operate over https anyway. It is not low priority as it blocks local testing and possibly confuses other users who might stumble on this problem.)