In my web application, which happens to be a SPA (Single Page Application), I have OpenID and OAuth2.0 clients for user authentication using third party service. Namely, Google (OpenID), Yahoo (OpenID), Windows Live (OAuth2) and Facebook (OAuth2).
Now, I have setup a token endpoint which exchange user credentials for a bearer token. The goal here is to replace Cookies by an Authorization header set in all requests of the SPA.
For this, I'm using the OAuth2.0 client password authentication strategy with a 'password' grant_type to authenticate the user based on its credentials (oauth2orize + passport-oauth2-client-password).
I am wondering :
How can I keep using the token bearer authentication method for users authentified using a 3rd party service ?
Is there anything in the OAuth2.0 spec which handles this case ?
What is the common practice for this kind of implementation ?
Related
Can OAuth be used for authentication (grand type - password flow) ??
I'm currently building a web application (microservices-based), and I want to implement OAuth for the authentication end-user, I choose to implement OAuth password flow, store the access token (JWT) in cookies, and validate that JWT token in the middleware.
After I do some research I found that OAuth is just for authorization, not authentication, is it correct? and how do I apply authentication with OAuth?
is the implementation of the OAuth password flow is not correct for my case?
You first authenticate (with user-password input or with 3rd party apps like Google Login). Then, later on you can use OAuth wherever needed.
I am currently looking to create a private web app with separate front-end and back-end on AWS using nodejs without signup and 3rd part logins, so generated user and passwords. I have looked over a few post, seems Oauth2 only provide more security when I am allowing 3rd party login or services, because it is a authorization framework. so I have a few questions:
In my case, I don't think authenticate oauth2 token is anymore secure than authenticate hash password. So I don't need oauth2 am I correct ?
Other than SSL on transfer and then use session-token after user login, what other ways I can make the backend API more secure ?
Please provide links or examples(best with nodejs )
Thanks,
I'm working on adding google login to my web app. It's a RESTful app, so once a user is logged in, each individual request must be authenticated with a token.
Currently, I create my own tokens using JWT. I can add useful information to the token object to help with state management.
My question is: once I add google as an authentication provider, do I then need send every request to Google to be authenticated, rather than authenticating it on my own server? Do I then lose the ability to customize the content of the token?
With external authentication providers, is it normal to manage separate JWTs for calls to your RESTful API?
Normally, you'll have the login action use the third party to identify the user. Your internal code will probably create/store/fetch an app local user profile of some sort, and you'll create your JWT based on that. Further calls to your API bearing a valid token are then trusted to have already been authenticated and therefore need no further calls to the auth provider.
I would like to give the users a possibility to login with some external oauth2 provider (facebook) in my app. The client's part is running on mobile device in a native app.
I am not sure which of the approaches below should I prefer ?
Should the client send the user's access token by facebook with each request ? At each request backend asks facebook to validate the access token. Based on the validation's result, backend performs authorization and return corresponding result to the client.
Should the backend ask facebook to validate the access token only at user logon, then issue its own access token, return the access token back to the client and client will use this access token at making requests to the server to avoid contacting facebook at each request ?
I have read some questions about how to implement the auth with facebook and most of the devs are using B, but I haven't seen any explanation why is it good/bad to use A ?
What I see as benefits of the solutions:
backend doesn't need to care about issuing, refreshing, validating access tokens since this is done only by facebook's authorization servers.
this solution seems to be more effective, since it does not require to connect to facebook at each request.
Security tokens issued by Facebook are signed with a digital signature. The API server only needs access to the public key to validate the signature. There's no need at all to contact Facebook after the user authenticates.
A reason to issue your own tokens after the user signed in with Facebook could be to add claims to the token. But obviously having your own authorization server comes at a cost. It's up to you to weigh the pros and cons.
If you do decide to have your own authorization server, make sure not to write your own! There are open source options like Thinktecture IdentityServer.
I will vote for option B and here is my explanation,
Your API must authorise the request every time with some auth token , which cannot be external provider token, in such case anyone with an access token (eg: other developers) of other provider can access your api, basically there is no auth here.
When your sever issue access token, it's easy to validate and when needed could be revoked easily (eg: on password reset)
While authenticating , your server has fully control over issuing access token , so the validation is made only once and doesn't have to do every time while calling the API.
I am developing a Javascript app + REST API.
I want users to authenticate with the app (and underlying REST API) via an OpenID Connect Provider for SSO purposes.
Using the Implicit flow I can get an ID token (JWT) identifying the user to my javascript app. I was hoping that I could then send this JWT in the Authorize header in requests to my REST API to authenticate the user. However, the problem with this approach is that the 'aud' field of the JWT won't be for the REST API server, it would be for the javascript app.
Does this mean Implicit flow is not suitable for my use case, or am I missing something?
Implicit Flow is designed for untrusted clients (such as JavaScript) to obtain identity and also (optionally) access tokens.
With OpenID Connect your authentication request must contain id_token in the response_type parameter, but it can also include token in the parameter too. See 3.2.2.1 in the spec (http://openid.net/specs/openid-connect-core-1_0.html#ImplicitAuthRequest)
e.g.
GET /authorize?
response_type=id_token%20token
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
&scope=openid%20profile
&state=af0ifjsldkj
&nonce=n-0S6_WzA2Mj HTTP/1.1
Host: server.example.com
id_token means that you will get back the ID token which you have mentioned. The token means that it will also return you an access token, which is what you would use for accessing your REST api.