Skip to content

GithubApp Auth #554

Open
Open

Description

@loonydev

Hi,
As I understand, for now this library don't support GithubApps authorization?

If so, I want to discuss the best way for implementation.

In my code I used trait GithubAuth with method def getAuthHeader():String. GithubClient taken instance of GithubAuth and call this function for token. In case of PAT it's return token from constructor, in case of private key it's looks like:

class GithubKeyAuth(privateKeyContent: String, appId: String) extends GithubAuth {

  implicit val clock: Clock = Clock.systemUTC
  // build PrivateKey instance from string
  private val privateKey = GithubKeyAuth.getPrivateKey(privateKeyContent)

 // generate valid JWT token using PrivateKey
  override def getAuthHeader(): String = {
    "Bearer " + Jwt.encode(JwtClaim({
      s"""{"iss":$appId}"""
    }).issuedNow.expiresIn(10), privateKey, JwtAlgorithm.RS256)
  }
}

WDYT?

Activity

  1. BenFradet commented on Sep 23, 2020

    @BenFradet
    Contributor

    You're right we don't support github apps authorization.
    However, I'm not sure about the best way to go about it as we don't want to handle jwt tokens directly in the library for example.

  2. loonydev commented on Sep 23, 2020

    @loonydev
    ContributorAuthor

    Agreed, maybe we can make GithubClient to accept instance of GithubAuth, so the user can use by default GithubPatAuth, in other cases they need to define own class.

    But if it's part of Github Auth flow user will do same code over and over.

  3. loonydev commented on Sep 28, 2020

    @loonydev
    ContributorAuthor

    So, do you have any suggestions how to implement it?
    I can do that, by I need to be sure that I don't waste a time.

  4. BenFradet commented on Sep 29, 2020

    @BenFradet
    Contributor

    maybe we can make GithubClient to accept instance of GithubAuth, so the user can use by default GithubPatAuth, in other cases they need to define own class.

    I'm 👍 on that

  5. loonydev commented on Sep 29, 2020

    @loonydev
    ContributorAuthor

    But as I mention before, users will do same code over and over and not in the best way. It's like give them domain and say, use own http sender.

  6. BenFradet commented on Oct 1, 2020

    @BenFradet
    Contributor

    We can add that code as documentation, it doesn't seem to me like the usage will be so huge that it would need to be part of the library.

  7. loonydev commented on Oct 1, 2020

    @loonydev
    ContributorAuthor

    Okay, next week I'm going to prepare this changes and will discuss it with real example.

  8. kusaeva commented on Nov 5, 2020

    @kusaeva
    Contributor

    @loonydev Hi! Are you still planning to make a PR with this changes?

  9. loonydev commented on Nov 9, 2020

    @loonydev
    ContributorAuthor

    Morning @kusaeva, not yet, it's in plan, but not in a near future. If you have a time to make it, it would be great.

  10. nmcb commented on May 23, 2023

    @nmcb

    Hello - I'm interested about the status of this issue

    We have a standalone service in our infrastructure that requires broad access to GH's REST api and the repositories under our organisation (DHL-Parcel) - preferably using the github4s library and authorise not via a personal access token - but either via JWT tokens or - as requested in this issue - via GH Apps authorisation.

    We did try the new AccessToken feature to get this working but weren't able to. The main issue seems to be the Authorisation: token header being hardcoded in the library, but we might not understand the way the new features was intended to be used. In that case an example would help us.

    If authorisation via JWT or GH App tokens is currently not possible we would able to spend some time on getting this to work with github4s provided that we get some help and pointers on how the preferred integration should look like in the API.

    Thanks in advance :)

  11. fedefernandez commented on May 31, 2023

    @fedefernandez
    Contributor

    Hi @nmcb, thanks for your interest.

    This is how it's currently built.

    We have an algebra that allows generating tokens:

    trait AccessToken[F[_]] {
    def withAccessToken[T](f: Option[String] => F[GHResponse[T]]): F[GHResponse[T]]
    }

    This algebra has a single implementation called StaticAccessToken. You pass a token, and it returns as a pure value.

    class StaticAccessToken[F[_]](accessToken: Option[String]) extends AccessToken[F] {
    override def withAccessToken[T](f: Option[String] => F[GHResponse[T]]): F[GHResponse[T]] =
    f(accessToken)
    }

    When you create a new Github4s client, it's creates an instance of that algebra to use it internally:

    new Github[F](client, new StaticAccessToken(accessToken))

    This is then used to create the internal GithubAPIv3 algebra:

    private lazy val module: GithubAPIs[F] = new GithubAPIv3[F](client, config, accessToken)

    That, in a similar way, pass it to the internal HTTPClient algebra:

    implicit val httpClient: HttpClient[F] = new HttpClient[F](client, config, accessToken)

    The HTTPClient uses the withAccessToken to get the token and pass it to the RequestBuilder

    withAccessToken(accessToken =>
    runWithoutResponse[Unit](
    RequestBuilder(buildURL(url)).withHeaders(headers).withAuth(accessToken)
    )
    )

    The RequestBuilder stores the token in a authHeader map, where the key is Authorization, and the value is s"token $token".

    def withAuth(accessToken: Option[String] = None): RequestBuilder[Res] =
    this.copy(authHeader = accessToken match {
    case Some(token) => Map("Authorization" -> s"token $token")
    case _ => Map.empty[String, String]
    })

    This is mapped to a Header.Raw

    self.authHeader.map(kv => Header.Raw(CIString(kv._1), kv._2))).toList

    Potential solution

    @loonydev's approach looks good, so I've created a draft with a potential solution:

    In that way, you can implement your algebra for generating auth headers, having complete control. Let me know your thoughts. The docs need to be updated accordingly.

  12. nmcb commented on May 31, 2023

    @nmcb

    thanks @fedefernandez! we'll give it a try.

    cc @thijsnissen

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions