Em suma, não. Mongo
ObjectIds são fáceis de adivinhar. Em particular, sob alta carga, geralmente são números consecutivos, porque o carimbo de data/hora, a máquina e o ID do processo não mudam. Se você observar a estrutura do Objectid
, são compostos por a 4-byte timestamp,
a 3-byte machine identifier,
a 2-byte process id, and
a 3-byte counter, starting with a random value.
Portanto, eles têm muito pouca aleatoriedade. Costumo ver IDs consecutivos no banco de dados, por exemplo, se alguma ação do controlador grava um objeto de domínio e uma entrada de log em rápida sucessão.
Se o carimbo de data/hora puder ser adivinhado e o ID da máquina for determinável (o que é, a menos que você tenha um cluster enorme), restam apenas cinco bytes. Ao olhar para um número de ids gerados, provavelmente posso reduzir isso para 50 processos, de modo que a entropia efetiva esteja em algum lugar na faixa de 28 bits. Isso ainda é difícil de adivinhar, mas é muito arriscado para um token de acesso.
Use um gerador de números pseudo-aleatórios criptograficamente forte e crie um token a partir disso. Por exemplo, em .NET, o
RNGCryptoServiceProvider permite criar dados aleatórios de comprimento arbitrário. Como nota lateral, sugiro ter um wrapper criptográfico adicional em torno de seus OAuthTokens, por dois motivos:
a) Você deseja determinar tokens inválidos rapidamente. Um shell criptográfico válido ainda pode incluir um token inválido (uma concessão revogada ou expirada), mas você não precisa acessar o banco de dados em ataques de força bruta todas as vezes. Também o cliente
b) Os clientes podem solicitar tokens repetidamente. Embora não seja um requisito, quase todos os sistemas que conheço retornam tokens diferentes todas as vezes (não importa se são autovalidados ou não). Normalmente, isso ocorre porque o próprio token tem um período de validade limitado. Esse não é o mesmo período de validade que a concessão OAuth tem.
No banco de dados, o que você realmente quer armazenar é a concessão, ou seja, a permissão que foi dada por algum usuário a algum cliente. Se essa concessão for removida, todos os tokens se tornarão inválidos. A inserção de um novo token sempre é muito inconveniente, pois o usuário teria que excluir todos eles para remover efetivamente a concessão do aplicativo.
