keratin/authn-go

Go client library for Keratin AuthN

authn-go's Issues

url-equivalent issuer comparisons

The URLs https://example.com and https://example.com:443/ can be considered equivalent issuers. The keratin/authn-rb library accomplishes this by coercing to URLs for comparison, but go's net/url library makes no assumptions (per golang convention).

Supporting this lenient issuer matching will take a bit more effort. It is not necessary for the library to function when configured precisely, though.

how do you get users details?

this client seems to be nothing like ruby client. how to make calls to authn?

SSO; single api server, multiple client applications

Support for one-of might be an interesting path forward but I'm also curious whether keratin/authn-go#15 also solves your issue?

One advantage to SubjectFromWithAudience is that it doesn't need to be pre-configured with a finite set of audiences at startup.

I'll close this issue on authn-server as it appears to be related to authn-go. Let's continue over there if you think there's more to discover.

Continuing the discussion from keratin/authn-server#193, client JWTs seem to only have a single entry in their aud field, i.e., the requesting domain. This means that SubjectFromWithAudience is still insufficient.

For example, given these identity tokens:

{
  "aud": [
    "client1.example.com"
  ],
  "auth_time": 1643740180,
  "exp": 1643743780,
  "iat": 1643740180,
  "iss": "https://auth.example.com",
  "sub": "1"
}

{
  "aud": [
    "client2.example.com"
  ],
  "auth_time": 1643740180,
  "exp": 1643743780,
  "iat": 1643740180,
  "iss": "https://auth.example.com",
  "sub": "1"
}

There seems to be no clear way to configure the authn-go client’s Audience or leverage SubjectFromWithAudience to pass validation. A jwt.Audience{} in SubjectFromWithAudience would work, but obviously drops audience verification, which seems important.

The proposal for oneOf in #14 seems to best fit this use case, but I’m not sure if there’s a way to accomplish this with the resultant SubjectFromWithAudience shipped in #15.

Does this make sense?

Getting the expiry time from the token?

https://keratin.github.io/authn-server/#/guide-confirm-password indicates that authn client libraries are able to extract the expiry/auth_time from the access token to prompt the user for a password. It seems that this capability is missing, but I've likely overlooked something.

need new release

There's a few things in master for the go release that we should get a tag out for so its available more widely.

Nats auth integration ?

Nats Jetstream can work with jwts, and so I was wondering if you think adding the ability to also register with NATS auth would be a good idea ?

Inconsistent AccountID type

Hi,

first of all thanks for the awesome authn-server project. I just noticed that authn-go has some inconsistencies regarding the accountID type. In ImportAccount and int is returned while the other APIs all like to get a string. Though, the API it self returns the Account ID as a number.

I'd be happy to file a PR to fix that inconsistency but what is the type you actually want to expose to authn-go users? Since the API uses a number I guess an int would be more correct but that would break backwards-compatibility with v1.0.0.

auth_time claim inaccessible from ClaimsFrom

#18 still doesn’t completely address extraction of the custom auth_time claim of authn-server’s Identity Token as it only returns the standard verified claims defined by go-jose.

This may require a change to ClaimsFrom, ClaimsFromWithAudience, IDTokenVerifier, and the JWTClaimsExtractor interface to return the Claims from the identities package in authn-server: https://github.com/keratin/authn-server/blob/main/app/tokens/identities/identity.go#L16-L19. Assuming https://github.com/keratin/authn-go/blob/master/authn/authn.go#L11 is still a desired outcome, this might be an opportunity to factor out jwt.Claims and replace with identities.Claims.

e.g., the patch could look something like this:

modified   authn/authn.go
@@ -5,6 +5,7 @@ import (
 	"net/http"
 	"time"
 
+	"github.com/keratin/authn-server/app/tokens/identities"
 	jwt "gopkg.in/square/go-jose.v2/jwt"
 )
 
@@ -68,13 +69,13 @@ func (ac *Client) SubjectFromWithAudience(idToken string, audience jwt.Audience)
 // if and only if the token is a valid JWT that passes all
 // verification requirements. If the JWT does not verify, the returned
 // error will explain why. This is for debugging purposes.
-func (ac *Client) ClaimsFrom(idToken string) (*jwt.Claims, error) {
+func (ac *Client) ClaimsFrom(idToken string) (*identities.Claims, error) {
 	return ac.claimsFromVerifier(idToken, ac.verifier)
 }
 
 // ClaimsFromWithAudience works like ClaimsFrom but allows
 // specifying a different JWT audience.
-func (ac *Client) ClaimsFromWithAudience(idToken string, audience jwt.Audience) (*jwt.Claims, error) {
+func (ac *Client) ClaimsFromWithAudience(idToken string, audience jwt.Audience) (*identities.Claims, error) {
 	verifier, err := newIDTokenVerifierWithAudiences(ac.config.Issuer, audience, ac.kchain)
 	if err != nil {
 		return nil, err

Extended audience verification options

This issue is a follow-up to the discussion in #13 where I will revert the change and wait for the outcome of the discussion on this issue.

Issue

Currently authn-go enforces audience verification against the audience set in Config.Audience. Since idTokenVerifier#L96 always passes Config.Audience to go-jose.v2/jwt.Validate it is not possible to disable audience verification at all (either for development purposes or because it's a strange requirement). In addition, it is not possible to let authn-go verify that at least one of multiple different audiences must be present in the JWT. This would allow easy integration into SSO solutions where each application (thus with a dedicated audience) needs access to common endpoint without using an application gateway (e.g. terminating TLS right before authn-server; ...)

The used JWT package go-jose.v2/jwt already supports passing multiple audiences to jwt.Validate although it then enforces the JWT to include all of those audiences rather then one or a sub-set.

Proposed solutions

Since there's already a discussion about a v2 release/client in #12 my proposed solutions here will not be backwards compatible with v1.

For the do-not-verify problem the solutions would be simple by just not specifying an audience for jwt.Validate if it's empty (or nil, see below suggestion).

In order to be able to satisfy both use-cases (the one-of and the all-of) I'd suggest the following API (implementation details to be discussed):

one-of

cfg := authn.Config {
    Issuer: "auth.example.com",
    // ... other fields
    Audience: authn.OneOfAudience("auth.example.com", "iam.example.com", "app1.example.com"),
}

The above example would count every JWT as valid as long as at least one of the above audiences is included.

all-of

cfg := authn.Config {
    Issuer: "auth.example.com",
    // ... other fields
    Audience: authn.RequiredAudiences("auth.example.com", "iam.example.com", "app1.example.com"),
}

In contrast to one-of, this will only accept JWTs that includes ALL of the mentioned audiences (which is AFAIK not really possible using authn-server right now).

Regex

As a really nice-to-have we could also extend this API with more complex verification and validation features like using regex or sub-domain matches:

cfg := authn.Config {
    Issuer: "auth.example.com",
    // ... other fields
    Audience: authn.AudienceMustMatch("lb[0-9]+\\.app\\.example\\.com"),
}

cfg := authn.Config {
    Issuer: "auth.example.com",
    // ... other fields
    Audience: authn.IsSubDomainAudience("example.com"),
}

Although, for the last tow (Regex/Subdomain) the behavior with multiple audiences would still need to be specified.