amazon web services - Autenticación Firebase vs AWS Cognito
amazon-web-services google-analytics (5)
En caso de que esté utilizando Unity, actualmente el Unity SDK no es compatible con el Grupo de usuarios de Cognito. (Es decir, AWS alojó la lista de usuarios) Actualmente estoy dudando debido a esto. Vea mi publicación here que confirmaron que es cierto, actualmente (26/06/2017) la función aún no está disponible, lo que podría mostrar una falta de atención para los usuarios de Unity.
Sin embargo, si uso Firebase para los inicios de sesión, necesitaría algunas integraciones más para que esas credenciales usen los servicios de AWS. (Me gustaría usar S3 y DynamoDB, pero solo el usuario registrado puede usarlo). Esto también me hizo darme cuenta de que debería mover todo a Firebase para ahorrar mi tiempo y frustraciones lo antes posible. (El DB en tiempo real es más caro que S3 / DynamoDB, pero Unity tiene su propio reemplazo de AWS MobileAnalytics)
AWS S3 recientemente tuvo una mejor interfaz de usuario, que creo que está cerca del nivel de Google. Pero aparte de eso, creo que la interfaz de usuario de Firebase es mucho más alegre de usar.
Además, la autenticación Firebase es gratuita, mientras que Cognito es gratis hasta 50.000 usuarios activos mensuales. (Los siguientes 50k costarán 0.0055, lo que significa que si tiene 100k MAU será 50000 * 0.0055 = 275 USD https://aws.amazon.com/cognito/pricing/ )
Una cosa más, la documentación de AWS .NET es una pesadilla para leer / buscar en mi opinión.
Estamos construyendo una aplicación móvil y web en AWS usando API Gateway y Lambda y estamos evaluando si deberíamos usar todos los servicios móviles de AWS (Cognito, Analytics, Mobile Hub, etc.) o si deberíamos usar Firebase (lo que ofrece algunas ventajas como configuración remota).
Creo que usar la parte no funcional de firebase como Analytics, Remote Config, Crash Reports, Notification debería estar bien con el backend de AWS. La parte de la que no estoy seguro es la capa de autenticación.
AWS Cognito se integra muy bien en API Gateway y Lamdba, por ejemplo, solo los usuarios autenticados pueden ejecutar ciertas llamadas a la API.
¿Se puede alcanzar el mismo comportamiento si usamos la autenticación Firebase en su lugar? ¿Alguna experiencia buena o mala con esto?
La documentación de Aws es bastante confusa. El sistema de devolución de llamadas para los diferentes pasos de autenticación se documenta mejor en Firebase. El resultado es un código más limpio y un mejor control sobre el flujo de autenticación. Además, la interfaz de usuario de Firebase es más fácil de usar. Si planea usar proveedores de contenido y adaptadores de sincronización, sugeriría usar Firebase porque tendrá métodos simples para la sincronización de datos entre la base de datos local y remota (Firebase).
TL; DR; Firebase> Cognito
Empezamos con Cognito primero, pero al final nos dimos cuenta de que tiene un olor atroz cuando se trata de usar Identidades Federadas (por ejemplo, inicio de sesión de Google, inicio de sesión de Facebook, etc.). Para los grupos de usuarios de Cognito (es decir, permitir que un usuario se registre / ingrese con un nombre de usuario y contraseña), puede usar el Autorizador de grupos de usuarios de Cognito de la puerta de enlace API integrado y funciona a la perfección. No necesitas escribir tu propio autorizador personalizado ni nada.
Sin embargo, si desea admitir identidades federadas, debe cambiar la autenticación en su puerta de enlace API a Autent IAM, y luego hacer que TODOS los clientes sigv4 firmen las solicitudes, lo que resultó ser una espina para nosotros y un costo significativo en el tiempo de desarrollo. La opción 2 era que la puerta de enlace API generara su código para sus llamadas a la API para cada cliente ... lo que en mi opinión es un testimonio de la complicada integración con Cognito.
Conseguimos que Firebase funcionara a través del autorizador personalizado para API Gateway Fue una brisa para todos los clientes (iOS, Android y Web). Los puntos finales de la puerta de enlace API se vincularon a las funciones Lambda, que pudieron comunicarse con DynamoDB, S3 y otros servicios web en nombre del usuario que llama al punto final. Las funciones lambda sabían quién era el usuario llamante porque el autorizador personalizado devolvía la dirección de correo electrónico en el JWT.
Aquí hay un autorizador personalizado bastante básico de Firebase que devuelve el correo electrónico del usuario en el JWT como el ID principal:
''use strict'';
console.log(''Loading function'');
var admin = require(''firebase-admin'');
var serviceAccount = require(''./my-secret-json.json'');
admin.initializeApp({
credential: admin.credential.cert(serviceAccount),
databaseURL: ''https://my-app.firebaseio.com''
});
exports.handler = (event, context, callback) => {
var token = event.authorizationToken;
if (token == null) {
callback(''Invalid token'');
}
else {
admin.auth().verifyIdToken(token)
.then(function (decodedToken) {
var email = decodedToken.email;
var policy = generatePolicy(email);
callback(null, policy);
}).catch(function (error) {
console.log(error);
callback(''Unauthorized'');
});
}
};
var generatePolicy = function (email) {
return {
principalId: email,
policyDocument: {
Version: ''2012-10-17'',
Statement: [
{
Action: ''execute-api:Invoke'',
Effect: email ? ''allow'' : ''deny'',
Resource: ''*''
}
]
}
};
}
Luego puede usar $context.authorizer.principalId en su plantilla de mapeo API Gateway para recuperar el correo electrónico y pasarlo a lambda X.
aws cognito ofrece más formas de autenticar usuarios que firebase. Especialmente, si está creando un juego, le da la posibilidad de iniciar sesión a través de los centros de juegos de Google y iOS. Proporciona tablas de clasificación de sincronización y proporciona logros de centro de juego. La característica de sincronización automática de estado está ahí en Cognito. Pero definitivamente, es muy confuso. Se necesita mucho tiempo para la implementación. Por otro lado, la autenticación Firebase es bastante rápida de implementar.
nosotros estamos haciendo lo mismo Comenzamos con Cognito, pero nos mudamos a Firebase porque no estábamos satisfechos con la forma en que el SDK de Android de AWS implementa el flujo de autenticación con Google y Facebook: el código es bastante antiguo, utiliza métodos obsoletos y generalmente requiere una nueva escritura. Por otro lado, la autenticación Firebase obviamente funciona sin problemas. Cuando no usa Cognito, necesita implementar su autenticador personalizado en AWS API Gateway, que es bastante fácil y se describe en https://aws.amazon.com/blogs/mobile/integrating-amazon-cognito-user-pools-with-api-gateway/ . Las instrucciones de Firebase para la validación de token se encuentran en https://firebase.google.com/docs/auth/admin/verify-id-tokens
El siguiente es un extracto del código de mi autenticador:
''use strict'';
// Firebase initialization
// console.log(''Loading function'');
const admin = require("firebase-admin");
admin.initializeApp({
credential: admin.credential.cert("xxx.json"),
databaseURL: "https://xxx.firebaseio.com"
});
// Standard AWS AuthPolicy - don''t touch !!
...
// END Standard AWS AuthPolicy - don''t touch !!
exports.handler = (event, context, callback) => {
// console.log(''Client token:'', event.authorizationToken);
// console.log(''Method ARN:'', event.methodArn);
// validate the incoming token
// and produce the principal user identifier associated with the token
// this is accomplished by Firebase Admin
admin.auth().verifyIdToken(event.authorizationToken)
.then(function(decodedToken) {
let principalId = decodedToken.uid;
// console.log(JSON.stringify(decodedToken));
// if the token is valid, a policy must be generated which will allow or deny access to the client
// if access is denied, the client will recieve a 403 Access Denied response
// if access is allowed, API Gateway will proceed with the backend integration configured on the method that was called
// build apiOptions for the AuthPolicy
const apiOptions = {};
const tmp = event.methodArn.split('':'');
const apiGatewayArnTmp = tmp[5].split(''/'');
const awsAccountId = tmp[4];
apiOptions.region = tmp[3];
apiOptions.restApiId = apiGatewayArnTmp[0];
apiOptions.stage = apiGatewayArnTmp[1];
const method = apiGatewayArnTmp[2];
let resource = ''/''; // root resource
if (apiGatewayArnTmp[3]) {
resource += apiGatewayArnTmp[3];
}
// this function must generate a policy that is associated with the recognized principal user identifier.
// depending on your use case, you might store policies in a DB, or generate them on the fly
// keep in mind, the policy is cached for 5 minutes by default (TTL is configurable in the authorizer)
// and will apply to subsequent calls to any method/resource in the RestApi
// made with the same token
// the policy below grants access to all resources in the RestApi
const policy = new AuthPolicy(principalId, awsAccountId, apiOptions);
policy.allowAllMethods();
// policy.denyAllMethods();
// policy.allowMethod(AuthPolicy.HttpVerb.GET, "/users/username");
// finally, build the policy and exit the function
callback(null, policy.build());
})
.catch(function(error) {
// Firebase throws an error when the token is not valid
// you can send a 401 Unauthorized response to the client by failing like so:
console.error(error);
callback("Unauthorized");
});
};
Todavía no estamos en producción, pero las pruebas en el autenticador muestran que se comporta correctamente con Google, Facebook y la autenticación de contraseña y también es muy rápido (60 - 200 ms). El único inconveniente que puedo ver es que se le cobrará la función lambda del autenticador, mientras que el autenticador integrado de Cognito es gratuito.