Will Sign in with Apple be a supported sign in method when it reaches public availability later this year?
Nobody’s been assigned to it yet but I suspect it’ll happen if they gain traction. Even if we don’t do it quickly in discourse core I think it’s likely someone in the community will create a plugin.
12 Me gusta
Cool. I hadn’t seen it mentioned anywhere yet, so thought I’d bring it up!
I could have a crack at this, given I just PR’d to the Discord one … how hard can it be? 
I also feel it’s important to support identity management with a company that is more privacy focussed that, ahem, others we could mention.
13 Me gusta
Do it @merefield!
As there is a omniauth-apple strategy already it should be doable GitHub - nhosoya/omniauth-apple: OmniAuth strategy for Sign In with Apple
16 Me gusta
Very useful, thanks Rafael
Estamos muy cerca, pero hemos encontrado un obstáculo:
La estrategia de OAuth requiere un archivo de clave pem (que obtienes de esas amables personas de Apple).
Cuando intento almacenarlo en un SiteSetting, el texto se corrompe de alguna manera y la generación de la clave privada falla:
::OpenSSL::PKey::EC.new(options.pem)
# OpenSSL::PKey::ECError
## invalid curve name
He intentado escapar el texto con \n donde hay saltos de línea.
No veo cómo esto pueda ser desplegable a menos que podamos almacenar de alguna manera el contenido de este archivo en un SiteSetting.
1 me gusta
El archivo .pem es solo la clave pública, ¿verdad?
En este caso, incluye la clave privada (aparentemente hay otras cosas codificadas en ella).
El código continúa usando esta clave privada para generar el secreto del cliente.
He probado la biblioteca con el archivo PEM y es válido, pero tan pronto como pegas el archivo en un SiteSetting (quizás predeciblemente), se altera sutilmente.
ACTUALIZACIÓN: parece que \n se reemplaza con \\n en los SiteSettings, por lo que quizás pueda buscar \\ al recuperar y reducirlo en uno.
Parece que pude solucionarlo, disculpa por el spam.
7 Me gusta
Una actualización:
Mi plugin parece estar funcionando hasta cierto punto, sin embargo, actualmente estoy recibiendo un error vago de Apple al intentar autenticarme con las credenciales que he configurado como Desarrollador de Apple:
“No se pudo completar su solicitud debido a un error. Por favor, intente más tarde”
Como pueden imaginar, esto no me da mucho en qué basarme.
Esto se complica ligeramente porque su esquema de autorización es muy diferente al estándar OAuth 2.0.
Desafortunadamente, aún no puedo abrir un ticket completo de TSI con Apple porque la función es prelanzamiento, pero presentaré un problema de Feedback.
El repositorio está aquí:
NB: Úselo bajo su propio riesgo; ¡aún no se ha probado con éxito!
7 Me gusta
¿Quizás usamos una carga de archivo para el archivo pem? ¿Qué tamaño tiene?
Es minúsculo 
El ‘archivo’ PEM (como una cadena en Configuración del sitio) parece procesarse correctamente, por lo que eso ya no parece ser el problema.
Ese error original ha desaparecido. JWT parece procesarlo correctamente ahora.
Lo solucioné reemplazando los saltos de línea con un signo y luego reemplazando el signo con un salto de línea al pasarlo a la función JWT. No es estándar, pero funciona. Proporcionar ‘/’ complica las cosas debido a la forma en que Ruby lo maneja. (Sin embargo, admito que, aunque no se genere ninguna excepción, esto podría seguir siendo un área problemática).
Eres más que bienvenido a usar tus credenciales de Apple y probarlo.
Temo que he cometido un error con las credenciales.
Necesitas proporcionar:
- ID del equipo
- ID del cliente
- PEM
- ID de la clave
Es muy engorroso configurar todo esto en el sitio web de Apple
8 Me gusta
@merefield ¡Lo tengo funcionando correctamente en sandbox.dtaylor.uk 
Tuve que hacer algunos cambios en nuestro fork para permitir la verificación del dominio. También agregué descripciones más específicas a la configuración del sitio y habilité el soporte de varias líneas para el PEM.
Parece que el gem omniauth-apple aún no soporta pasar información sobre el usuario… lo cual no es muy útil para nosotros. Parece que sign-in-with-apple es casi compatible con OpenID-Connect, por lo que es posible que podamos reutilizar parte de la funcionalidad de ese plugin.
En cuanto a la configuración de las credenciales, encontré que esta publicación de blog (con un nombre muy apropiado) fue mucho más útil que la documentación de Apple:
11 Me gusta
¡Eso es genial! Ah, textarea es nuevo para mí. Eso evita muy bien mi «parche» que añadí. ¡Perfecto! ¡Ojalá lo hubiera sabido antes! 
Me gusta la verificación del archivo txt que añadiste, buen detalle. Yo lo hacía manualmente, pero es una gran ayuda para el uso en producción.
Sí, yo también lo usé.
Lamentablemente, sigo obteniendo el mismo error del lado de Apple después de fusionar tu fork, así que sospecho que todavía estoy haciendo algo tonto con las credenciales. ¡Quizás te envíe un mensaje privado para intercambiar notas! 
7 Me gusta
OK, resultó que mi problema era casi con seguridad intentar acceder desde un sitio parcialmente en desarrollo (aunque se ejecutaba con nginx y sobre HTTPS).
Lo intenté de nuevo con un sitio de producción y
pero, desafortunadamente, como bien dices, no se devuelve el campo “Name” y esto debe ser culpa del middleware, ¿verdad? Parece que Apple permite autorizar esto.
¿Estamos seguros de que devolverá un nombre? Desde una perspectiva de privacidad, es casi mejor que el usuario elija un nombre a que se divulgue cualquier información de identificación personal (PII) pública en el proceso.
Técnicamente debería hacerlo, ¿verdad? Pero estoy de acuerdo con tu punto, aunque puedes elegir no exponerlo en la página de Apple. Al final, resulta que es irrelevante hasta ahora.
Sí, alguien había planteado un problema sobre esto, pero luego fue cerrado.
Supongo que este es el área de código que nos preocupa:
info do
{ sub: id_token['sub'] }
end
mientras que en la gema de autenticación de Discord, por ejemplo, obtenemos esto:
info do
{
name: raw_info['username'],
email: raw_info['verified'] ? raw_info['email'] : nil,
image: "https://cdn.discordapp.com/avatars/#{raw_info['id']}/#{raw_info['avatar']}"
}
end
Por si acaso, no hay mención de esos campos en la documentación de la API de Apple …
Parece que este PR agrega información útil del usuario: Use JWT gem and some refactor by fjaeger · Pull Request #7 · nhosoya/omniauth-apple · GitHub. Ojalá se fusionará pronto, o si no, podríamos considerar usar un fork.
5 Me gusta
Sí, tienes razón. Vi esa PR pero no profundicé en el código y pensé que simplemente se cambiaba a una dependencia diferente. La gente debería considerar no enviar PRs con un alcance tan grande, ya que detalles como ese pueden perderse.
Como dijiste:
{
sub: id_info['sub'],
email: user_info.dig('email'),
first_name: user_info.dig('name', 'firstName'),
last_name: user_info.dig('name', 'lastName'),
extra: {
raw_info: id_info.merge(user_info)
}
}
He añadido un comentario para apoyar la PR.
4 Me gusta