I am an azure user and I am using the mobileservice client to generate azure tokens from oAuth provider tokens.
I want to let users securely read/write to MY API, and it appears that the only unique identifier that it gives me is an integer userID. The token, a more difficult to guess string, appears to change every time I generate an unauthenticated client.
What is the best practice for doing this? Could someone just open a client with my appkey, guess the 25 character user ID, and then call my api?
How can I use the token to provide secure read/write to my api? Or is using the User ID,https, obfuscation, etc my best bet? Maybe i could use a tutorial on how tokens work.
There are two or three pieces here.
1) The OAuth provider (Facebook, Google, etc.) is likely providing you a cryptographically signed JSON Web Token (JWT) - secure and trusted
2) The ZUMO token is likewise a JWT - cryptographically signed and can be trusted.
3) You can convert the JWT to the claims that are backing the JWT by called getIdentity() (node.js server SDK) or GetIdentityAsync<> (ASP.NET server SDK)
You can find some information on my blog: https://shellmonger.com/2016/04/08/30-days-of-zumo-v2-azure-mobile-apps-day-5-custom-authentication/ - I'm right in the middle of discussing authentication for Azure Mobile Apps.
Related
I've followed a training in Go as an introduction to microservices architecture a while ago. Getting back to this project I realise that I need more context as we've been quickly digging into the details of the implementations at the time...
I've drawn a simplified sequence diagram of 2 simple use cases:
The user logs in
The user is already logged in and make a purchase
(you can comment / modify the diagram at your convenience)
https://drive.google.com/file/d/1gWgkhJipUvWrVidkl7YFt_xlDmZYn_CX/view?usp=sharing
Here are the questions I have:
Here we're dealing with user authentication but what about client authentication? In the case of a web front end client, can I imagine storing an api_key and an api_secret in the env variables for the server that will be hosting this client? Because there use cases where the user is not logged but some services still needs to be available, but at the same time I only want my known clients (the web front and the mobile app) to be able to access those services (putting aside API Gateway solutions, and maybe other API Shields which would probably add another security layer against DOS etc.)
If the client logs in using Google/Facebook, the front app will receive an id_token that needs to be passed to the backend which would then verify the token ( https://developers.google.com/identity/sign-in/web/backend-auth ). In this particular case my OAuth API would not be used. Could please you confirm that it's the way it should be handled?
Many thanks.
EDIT 02/05/2022
Intro / Context
First thing first, Authorization is not Authentication.
Authentication is the process of verifying who a user is,
while authorization is the process of verifying what they have access to.
And like #Max said, OAuth is designed to manage Authorization and Open ID Connect (OIDC) is an extension of OAuth to manage Authentication on top of it.
The diagram I've exposed in my question is known in the OAuth world as the password grant, and, from the official documentation :
Because the client application has to collect the user's password and
send it to the authorization server, it is not recommended that this
grant be used at all anymore.
Authorization of my App (to get access to my APIs)
From the API perspective, we just want to ensure that the incoming requests are coming from the server that is hosting the App. So, in my case, it's simple machine-2-machine communication from backend server to backend server and there's no action required from the user. So, I must implement the Client Credentials Flow
...which would lead me to this flow:
https://drive.google.com/file/d/1qE9JpWRSRPa8z5iNxm7ocGkeT0E149Sv/view?usp=sharing (Feel free to comment / rectify )
Authentication of a user
Because OAuth knows nothing about authentication, I need an OIDC flow. The easiest one is based on the Authorization Code Flow with PKCE from OAuth below (only about authorization) ...
... but the difference is that we're passing an additional scope named openid in the authentication request (step 3), when the app performs the 2nd request to the token endpoint (step 7), the auth server returns an ID Token (which is a JWT containing user info in the payload -> authentication) in addition to the access_token (which do not contain user info but just "random string"). There's other OIDC flows with their pros & cons depending on the situation but it's another topic on its own (https://openid.net/specs/openid-connect-core-1_0.html)
User already identified by Google/Facebook
In case the client logs in using Google, the front app will receive an id_token. This token could be sent to the app server which would then make a request to the API Gateway, which then call the Auth api which would be in charge of verifying the token by calling the 3rd party auth server ( https://developers.google.com/identity/sign-in/web/backend-auth ).
In case of Facebook, we get back an access token, so I don't know how to deal with it ...
https://developers.facebook.com/docs/facebook-login/web
https://developers.facebook.com/docs/facebook-login/guides/advanced/manual-flow
Using Firebase, there's an onAuthStateChanged callback, so from the App perspective it will prevent request without the user being logged in, but from the API perspective, it doesn't guaranty that a request is coming from a logged in user...
https://firebase.google.com/docs/auth/web/manage-users#get_the_currently_signed-in_user
Warning: the answer below is not complete, it only serves to give a rough idea
Intro
OAuth2 is a protocol for authorization.
Grant Types
Over the OAuth2 protocol, you can use one of the "grant types" or "flow", one of these flows is illustrated in the picture you post and named password grant.
Each of these flows is realized for different scenarios, you rightly point the attention to how securely store the password on a web app.
For example for a front-end authentication (javascript / wasm) you can use a PKCE Flow where the secret_id is not used.
Endpoints
On OAuth2 there are two primary enpoints
Authorize endpoint - where you obtain the authorization code
Token endpoint - where you exchange the authorization code for the token(s)
Tokens
There are two types of tokens on OAuth2
Access Token
Refresh Token
The definition of token on OAuth2 is "an opaque string", you don't need to read it.
The access token is used against the API, this token has an expiration date, when it is expired the system use the refresh token to get another access_token whitout user interaction, when the refresh_token expire the user must re-authenticate again.
You can read the content of the access_token (which is a JWT token) from the JWT.io
Scopes
The Access token has, on its body, the scopes (i.e. Read email, read name, etc).
Scope is a mechanism in OAuth 2.0 to limit an application's access to a user's account.
Identity
On top of the OAuth2 are build other protocols OIDC aka IdToken aka Open Id Connect is one of them, in other terms OIDC protocol use the OAuth2 for establish an Authentication.
With the OIDC there is another token the id_token, this token came with the user's info and is NOT used has Authorizization in front the API.
There are also OIDC flows you can use to get the id_token and/or the access_token.
Conclusion
I suggest you read about OAuth2 from the references below and try different flows using the playground
References
Which oauth2 flow should I use
OAuth2
PKCE in more depth
My advice is to start with the data, which is the deeper area of OAuth.
USE AN AUTHORIZATION SERVER
This will enable you to keep your code simple. It will also handle Google / Facebook and many other forms of authentication for you, with zero impact on your code. The Curity Community Edition is a free and developer friendly option, though there are others. eg Keycloak, Ory Hydra.
PROTECT DATA
OAuth primarily gives you modern ways to protect data. Use scopes and claims to protect data across multiple microservices in a zero trust manner while securely maintaining user context. You will also need to manage joining identity and business data.
IMPLEMENT UI FLOWS CORRECTLY
Mobile apps use the AppAuth pattern. The current best practice for browser based apps is a Backend for Frontend approach. Both of these are tricky.
KEEP CODE STANDARDS BASED
All of the above Curity resources are based on OAuth related standards. If followed your apps will stay simple, with portable code, that can also work with other providers.
OAuth is very architectural though, and the best designs take time to learn, but you can learn the intricacies gradually. Our IAM Primer is a good starting point.
Lets say I have a web API that a native application needs to make requests to. This API needs to authenticate who the user is that's making these requests via the native app. OpenID Connect seems to be the right choice since it is about authentication rather than authorization with OAuth.
The native app sends the users credentials to the IDP and gets back an access token (for authorization) and an id token (for authentication). From what I understand of OIDC, the access token would be sent to the API but the id token is only for the native client app. That doesn't make sense to me because it's the API that cares about who the user is, not the native app.
So why isn't the id token also passed to the protected resource (aka the API)? If you don't pass the id token to the API, what guarantees that the access token is secure and can be used to authenticate the user? Otherwise it would seem to lose the benefit of using OIDC over OAuth.
The OIDC Specification is designed in a way that ID tokens are always for Clients (Native app) and Access tokens are for resources (APIs). The ID tokens are always JWT tokens, but the Access tokens can be of different type.
The purpose of Access token is not to authenticate but to Authorize (Delegated Authorization). If, for some reason, the resource server wanted to know about the user, it can call the user-info endpoint.
The security/validity of token exchange can be validated in several ways:
Using encryption/signature with Public/Private key model where Authorization server encrypts / signs the access token with its private key and resource server decrypts / verifies with the public key.
Using token introspection endpoint to validate the claims, validity of the token etc..
Other attributes like AUD , AZP help in validating the issued access tokens.
Some OIDC providers use ID_Tokens to access API's - this is different to the model suggested by OIDC specification
This article has detailed explanation about these scenarios.
I read articles on choosing the right authentication mechanism and I understand that JWT just defines a token while OAuth is a full framework that can use JWT. There are also other frameworks (Firebase?) and token-standards.
Now for my specific use-case I have a single-page-, microservice app with Angular2 that will run the whole day in the browser without any refreshing, in a rather old B2B environment (2GB ram, IE11). So social logins are not needed and a lightweight solution is preferable. Can you suggest anything?
This questionary could help
Are you using a forms based web or a SPA?
Forms: Use server sessions
SPA: Use authentication tokens (JWT or opaque)
Using authentication tokens, do you want to avoid storing session data at server side?
Yes: Use JWT
It does not matter: Use opaque tokens
The client needs to verify token or extract token claims?
Yes: Use JWT signed with RSA
No: Use JWT with HMAC or opaque tokens
Do you have an API for third party?
Yes: Use OAuth2 or OpenIDConnect issuing authentication tokens after succesful user login
No: Nothing extra
Do you want to manage user passwords?
Yes: Make your own registration and login forms
No: Integrate social logins (they use oauth/OIDC)
I have a web application in node js that consumes an API for certain aspects of the content of the website e.g news. The API is written in node.js and points to a mongodb database.
I would like some advice as to the best authorization strategy for this type of requirement. I don't really need a user-name and password solution (I don't think). Some sort of static token that the web app can pass to the API so that only applications that have this token can browse the data returned by the API. I mainly want to stop just any old application consuming the API.
Here is best blog that can help you how to authenticate the REST Api in node js with the help of Basic HTTP Authentication, Oauth1 And Oauth2
https://stormpath.com/blog/secure-your-rest-api-right-way
Basically there are the three type of authentication that generally used
Basic Authentication
Oauth1.0a
Oauth2
Http Basic Authentication
More convenient, as you can easily expire or regenerate tokens
without affecting the user's account password.
If compromised, vulnerability limited to API, not the user's master
account
You can have multiple keys per account (e.g. users can have "test"
and "production" keys side by side.)
Oauth1
OAuth 1.0 requires client to send two security tokens for each API call, and use both to generate the signature. It requires the protected resources endpoints have access to the client credentials in order to validate the request.
Oauth2
OAuth 2.0 signatures are not required for the actual API calls once the token has been generated. It has only one security token.
Here describes the difference between OAuth 1.0 and 2.0 and how both.
I'm trying to build a mobile app that has a login functionality with an ASP.NET web api, and I need to implement the token based authentication,
what I need is, as a first time the user login using username and password, a new token will be generated with expire date along with a refresh token, I'm thinking of the refresh token because the user doesn't have to login every time the token expires,
the token is saved in the mobile device and in the database, so with each request, sends the token whether in the request header or with the posted data,
I don't exactly know how the token based authentication works in terms of sending the token encrypted or hashed to the user and processing the request in the server
Edit:
an attacker in the middle can just read the token and start sending requests to the server using the token. I mean he doesn't need to know what the token actually means.
I created a class that has these properties (UserID,Token, RefreshToken, ExpiryDate), but I read that it is not a good approach,
I'm using AES for encryption and SHA256 for hash
Thank you for you help,
Please see the following articles in order to understand how token based authentication works in ASP.NET Web API.
http://www.codeproject.com/Tips/821772/Claims-And-Token-Based-Authentication-ASP-NET-Web
http://bitoftech.net/2014/06/01/token-based-authentication-asp-net-web-api-2-owin-asp-net-identity/
Search OpenID and OpenID Connect specs, they will tell you exactly how the tokens should work in your case (non-confidential implicit client flow). You can add OpenID endpoints easily to your asp.net web api if you don't want to use an external openid server.