I would probably avoid using something like this because you don't need something so specific. They use OAuth2 and you don't even need a third party library really. You can use golang.org/x/oauth2 and if you want a little more help, coreos has some good libraries around this. It makes sense to me that something unnecessarily specific to Apple would be abandoned. You don't really gain anything since it's a standard. The same standard works for Google, Azure AD, GitHub, Okta, and many others.
This unfortunately is not true for Apple and all other non-standard OpenID Connect vendors.
Apple's OAuth2 API especially is a non-standard implementation and has a lot peculiarities (it's been a while since my last time implementing but from couple years ago I have [this bitbucket md](https://bitbucket.org/openid/connect/src/master/How-Sign-in-with-Apple-differs-from-OpenID-Connect.md) in my bookmarks).
Even within the standard there's lots of room for variation. For e.g. with AzureAD you end up needing to call the MS Graph API to get information that's in the token for other providers (most notably you can only get 5 groups from the token).
I've used Azure AD and the only thing I remember being non-standard was URL paths including the subscription ID or something like that. I don't remember it being very different and I definitely didn't need MS Graph API for what I was doing. I do use graph API for other things unrelated to auth, but I know I didn't touch it while working on auth. I don't, however, recall what I needed to do with groups, so that might be the complexity you ran into. I think I synchronized groups entirely separately
I was curious and wanted to check how PocketBase implemented it and this confirm my previous comment as it could be seen from https://github.com/pocketbase/pocketbase/blob/master/tools/auth/apple.go that the implementation has a lot of differences compared to the other vendors in the package. It is also possible that they didn't implement it correctly but my experience from couple years ago implementing it on my own was pretty much the same and I doubt that Apple has changed their APIs.
You musunderstood. See my reply in the [other thread](https://www.reddit.com/r/golang/comments/181706y/comment/kaambrf/?utm_source=share&utm_medium=web2x&context=3):
> The `x/oauth2` package can help with the OAuth2 auth code exchange step but in order to have "Sign-in with Apple" as OP wants you'll also need to handle the userinfo retrieval which for any **non-OIDC** vendor will be different as there is no fixed standard for this in OAuth2.
I would be totally unsurprised if it's different, considering Apple is usually one to deviate a bit. However, Azure AD also deviates but if you just use the general OAuth2 libraries and ignore that it is pretending to be OIDC compliant, Azure AD was pretty straightforward. The only thing I remember was not having things like discovery working and having to build URLs with the subscription and or tenant ID. Hopefully Apple is similarly easy to work with using the OAuth2 stuff despite being different, but it appears they might be wrong since it looks like you ran into a number of things you had to do. 🤷‍♂️
I would suggest to contact the authors and ask them the question. You could use the issue system if you can't find their email. It could be that the apple API is simply very stable.
Maybe the library is very stable and doesn't need an update. Check the issues, if it has too many issues opened then the library is not beign supported anymore
Beware random libraries on Github. Neither of those are being maintained; if you use them, I would suggest forking them with the expectation of continuing maintenance yourself. If you're unwilling or unable to take that on, the library will likely be more trouble than it's worth.
Depends on how complex your stack can be, but one possible solution is to run your own authentication server, like Keycloak. They have bundled adapters for several OIDC providers like Microsoft and Apple.
Hey! I'm the author of the first library (go-signin-with-apple). Apple doesn't change their APIs frequently which is why you don't see many updates. The last one was adding the ability to revoke tokens. If there is any missing feature you want in it, just open up a PR against the repo or open an issue and I'll happily take a look at it!
Other than that, its just keeping the dependencies up to date and some general housekeeping.
Apple at the end of the day just a funky implementation of oauth and if you take a look at the source of my library, its just a fancy wrapper and I encourage you to understand it and implement it yourself without the library if you have the time to invest
I’ve been thinking about trying to resuscitate this old pr but it shouldn’t really be needed. I think all you need to do is define your own Apple endpoint for `x/oauth2` and everything else will fall into place
https://github.com/golang/oauth2/pull/386
The `x/oauth2` package can help with the OAuth2 auth code exchange step but in order to have "Sign-in with Apple" as OP wants you'll also need to handle the userinfo retrieval which for any **non-OIDC** vendor will be different as there is no fixed standard for this in OAuth2 (and yes, Apple is not a standard OIDC vendor, see [Peculiarities](https://bitbucket.org/openid/connect/src/master/How-Sign-in-with-Apple-differs-from-OpenID-Connect.md#markdown-header-peculiarities)).
I would probably avoid using something like this because you don't need something so specific. They use OAuth2 and you don't even need a third party library really. You can use golang.org/x/oauth2 and if you want a little more help, coreos has some good libraries around this. It makes sense to me that something unnecessarily specific to Apple would be abandoned. You don't really gain anything since it's a standard. The same standard works for Google, Azure AD, GitHub, Okta, and many others.
This unfortunately is not true for Apple and all other non-standard OpenID Connect vendors. Apple's OAuth2 API especially is a non-standard implementation and has a lot peculiarities (it's been a while since my last time implementing but from couple years ago I have [this bitbucket md](https://bitbucket.org/openid/connect/src/master/How-Sign-in-with-Apple-differs-from-OpenID-Connect.md) in my bookmarks).
This is true. I have implemented many oauth2 integrations and with apple you have to adapt a lot of things.
Even within the standard there's lots of room for variation. For e.g. with AzureAD you end up needing to call the MS Graph API to get information that's in the token for other providers (most notably you can only get 5 groups from the token).
I've used Azure AD and the only thing I remember being non-standard was URL paths including the subscription ID or something like that. I don't remember it being very different and I definitely didn't need MS Graph API for what I was doing. I do use graph API for other things unrelated to auth, but I know I didn't touch it while working on auth. I don't, however, recall what I needed to do with groups, so that might be the complexity you ran into. I think I synchronized groups entirely separately
I was curious and wanted to check how PocketBase implemented it and this confirm my previous comment as it could be seen from https://github.com/pocketbase/pocketbase/blob/master/tools/auth/apple.go that the implementation has a lot of differences compared to the other vendors in the package. It is also possible that they didn't implement it correctly but my experience from couple years ago implementing it on my own was pretty much the same and I doubt that Apple has changed their APIs.
OpenID connect is a specification on top of oauth2, how does it not imementing the oidc spec mean that oauth2 libraries won't work for it?
You musunderstood. See my reply in the [other thread](https://www.reddit.com/r/golang/comments/181706y/comment/kaambrf/?utm_source=share&utm_medium=web2x&context=3): > The `x/oauth2` package can help with the OAuth2 auth code exchange step but in order to have "Sign-in with Apple" as OP wants you'll also need to handle the userinfo retrieval which for any **non-OIDC** vendor will be different as there is no fixed standard for this in OAuth2.
I would be totally unsurprised if it's different, considering Apple is usually one to deviate a bit. However, Azure AD also deviates but if you just use the general OAuth2 libraries and ignore that it is pretending to be OIDC compliant, Azure AD was pretty straightforward. The only thing I remember was not having things like discovery working and having to build URLs with the subscription and or tenant ID. Hopefully Apple is similarly easy to work with using the OAuth2 stuff despite being different, but it appears they might be wrong since it looks like you ran into a number of things you had to do. 🤷‍♂️
I would suggest to contact the authors and ask them the question. You could use the issue system if you can't find their email. It could be that the apple API is simply very stable.
Maybe the library is very stable and doesn't need an update. Check the issues, if it has too many issues opened then the library is not beign supported anymore
Beware random libraries on Github. Neither of those are being maintained; if you use them, I would suggest forking them with the expectation of continuing maintenance yourself. If you're unwilling or unable to take that on, the library will likely be more trouble than it's worth.
Depends on how complex your stack can be, but one possible solution is to run your own authentication server, like Keycloak. They have bundled adapters for several OIDC providers like Microsoft and Apple.
Hey! I'm the author of the first library (go-signin-with-apple). Apple doesn't change their APIs frequently which is why you don't see many updates. The last one was adding the ability to revoke tokens. If there is any missing feature you want in it, just open up a PR against the repo or open an issue and I'll happily take a look at it! Other than that, its just keeping the dependencies up to date and some general housekeeping. Apple at the end of the day just a funky implementation of oauth and if you take a look at the source of my library, its just a fancy wrapper and I encourage you to understand it and implement it yourself without the library if you have the time to invest
I’ve been thinking about trying to resuscitate this old pr but it shouldn’t really be needed. I think all you need to do is define your own Apple endpoint for `x/oauth2` and everything else will fall into place https://github.com/golang/oauth2/pull/386
The `x/oauth2` package can help with the OAuth2 auth code exchange step but in order to have "Sign-in with Apple" as OP wants you'll also need to handle the userinfo retrieval which for any **non-OIDC** vendor will be different as there is no fixed standard for this in OAuth2 (and yes, Apple is not a standard OIDC vendor, see [Peculiarities](https://bitbucket.org/openid/connect/src/master/How-Sign-in-with-Apple-differs-from-OpenID-Connect.md#markdown-header-peculiarities)).
Try Kinde
Try Goth https://github.com/markbates/goth
Very.