I have been analyzing security process in 3gpp specs and the registration process in the spec. explained with that flow. The flow represents the registration of a client to the server..
I am not a security specialist and i do not understand why we send Oauth2 token in step 1. Doesn't the access token send after the registration? I know that the access token used for authorization if the client known. I know that is a weird topic and I tried to explain it briefly i hope you understand if you dont you can always ask me.
Related
I have a few concerns with an OpenId Connect strategy that I would like to use and have been unable to find specifics on what the security concerns may be and any glaring issues with it I am overlooking.
Currently, I have an OpenId Connect implementation using Openiddict with Authorization Code flow. For the client, I have a React-Native app using react-native-app-auth.
I see from other questions on SO and from issues posted on the Openiddict repo that the recommended approach to third-party providers (e.g. Google) is: Client -> Auth server -> Google Auth -> Auth server -> Client/Auth server code and token exchange
However, it seems that a better approach from a UX standpoint (when using a SPA or native app) would be to implement something similar to GoogleSignIn on the client and either handle the identity on the server using an IdToken or authorization code from Google. This introduces an issue as the flow previously recommended could not be used as the entire initial challenge and redirect from Auth server to Google Auth has been skipped.
I have seen that this issue is mitigated by not using the authorization code grant and instead implementing a custom assertion grant. This seems to be an alright approach but would require exposing a custom grant and handling the flow differently on the client and server for local and third-party logins.
My proposed solution continues to use the authorization code flow and instead of adding a custom grant type the client could just pass a third-party identifier "Google" and the token or authorization code in the additional parameters of the OIDC authorize request. The authorize endpoint could then detect the provider and token, perform token validation, create a user or principal from it, and create an authorization code to send back to the client for the code/token exchange. This flow would look like the following:
1. Get the id token from the provider Client -> GoogleSignIn -> Client
2. Pass token to auth server and initiate code / token exchange Client -> Auth Server -> Auth server Verify Google IdToken (JWKS, issuer, audience, provider specific validation, etc...) or exchange auth code -> Auth server -> Client/Auth server code and token exchange
One downside to this approach would be the additional hops to verify the token on the server side. If the token was returned from GoogleSignIn, they themselves said that it could be trusted. https://developers.google.com/identity/protocols/oauth2/openid-connect#obtainuserinfo
I see that it is generally recommended to place the auth server between the client and the third-party but in this process the server is still between the client and auth server but only after the initial exchange from the client and third-party.
Questions,
In general am I missing something with this flow?
In this case would it be necessary to verify the token on the server side?
Is there some better way to approach this that I have completely overlooked?
Am I making this too complicated and UX should not be this much of a concern?
Instead of adding the provider and token to the additional parameters would it make more sense to pass it in the body of a post request? I don't see the issue with passing it via query string but that's also part of the reasoning for the authorization code grant from my understanding.
Apologies in advance for anything I have missed or omitted for brevity that should have been included.
Thanks.
ARCHITECTURE
I'm not sure I understand the UX problem - your existing architecture feels really good. If you want to login directly to Google, just send an acr_values=google query parameter in the authorization redirect, to bypass any authentication selection screens. The exact value will depend on how Openiddict represents the Google authentication option, and some providers use a non-standard parameter such as idp. Have a closer look at the OIDC request parameters.
A key OAuth goal is that the Authorization Server (AS) - Openiddict in your case - shields your apps from all of the provider differences and deals with their nuances and vendor specific behaviour. Your apps then also only receive one type of token, and only ever use simple code. As an example, the Curity AS supports all of these options, none of which requires any code in applications.
APPAUTH AND UX
If a user is already signed in then it can, as you say, look unnatural to spin up the system browser and them it is dismissed immediately.
A common option is to show the consent screen or an interstitial page to keep the user informed - and the user clicks one extra button. This can also be useful for getting password autofill to work. My code example and blog post shows how this might look, though of course you can improve on my basic UX.
OFFLINE ACCESS
I find this term misleading, since refresh tokens are most commonly used when the user is there. Are you just asking how to deal with tokens in a mobile client? Aim for behaviour like this:
Standard messages for API calls with access tokens in an authorization bearer header
Standard refresh token grant messages to refresh access tokens - eg as in this code
Note also that mobile apps can save tokens to encrypted secure mobile storage that is private to the app. This can improve usability, eg by avoiding logins every time the app is restarted. You should think through scenarios such as stolen devices and token lifetimes though.
I am a newbie to .Net Core WebAPI authentication. I've figured out OpenIddict is one of the authentication service easy-to-use but before I start using it I noticed there are samples with different authentication flows in GitHub. I could not find any documentation around these authentication flows so the below questions come to mind.. Appreciate if someone can provide insights on the area.
GitHub url : https://github.com/openiddict/openiddict-core
Why there are different flows.. which one to use? I am guessing each flow fits to different nature of application if so,
a. what are the pros and cons of each flow?
b. Is there any best practice or guidelines that helps to determine the right option (authentication flow) that fits in for that particular application?
Thanks in advance.
Why there are different flows.. which one to use?
OpenIddict is an OAuth2/OpenID Connect server. As such, it implements all the classical core flows defined by these two specifications.
As you figured out, each flow has a different use case:
The client credentials grant is used when a headless client application needs to access its own resources. No user is involved in this flow, which is basically a server-to-server scenario.
The resource owner password credentials grant is the simplest OAuth2 flow: the client application sends a token request with the username and the password of the user and it gets back an access token. This flow is sometimes considered as a "legacy" flow and must not be used by third-party apps you don't manage yourself (because it's the only flow where the client knows the user credentials).
The code flow is the most complex OAuth2/OpenID Connect flow that uses redirections and allows creating consent pages where the user can decide whether he wants to grant an access to the client application without ever sharing his credentials with the app.
The implicit flow is a simplified code flow, made for browsers-based apps.
For more information, you can read this blog post: http://kevinchalet.com/2016/07/13/creating-your-own-openid-connect-server-with-asos-choosing-the-right-flows/.
It's a know problem that Instant Flow struggles from confused problem, so you have to check whether access_token you received was given to your application.
I always considered it's not a problem for Authorization Code flow but in this answer it was mentioned it is not so and you have to verify token even in Authorization Token flow.
But honestly I can't figure out a workflow where it's necessary. Like we receive a code and then make direct request for a token (specifying client_secret). I don't understand how we could be forced to use a wrong token in this flow.
The answer that you refer to talks about an access_token delivered to a Resource Server. That is also in general where the "confused deputy" issue applies.
In your post you refer to the Authorization Code delivered to the Client. That is different and does not suffer from the same confused deputy attack as described.
It should be noted though that the Authorization Code grant type may be vulnerable to a related attack ("Authorization Server Mixup") if the Client talks to multiple Authorization Servers (AS) somewhat for the same reason: the Client is not able to detect if the Authorization Code is actually issued by the AS that it thinks it talks to. Registering a Redirect URI that is specific for each AS addresses this.
I' am new to oAuth but I have read it's theory and I know about flow of different things in oAuth but I have a small confusion though.
I want to make my Windows App as a Consumer and my API Server a Provider in terms of oAuth. I' am using a library to make proper workflow of oAuth and my oAuth Server (API Server) returns access_token when user is authenticated and for each request to API Server that access_token is used to authenticate user. Now if I login with same account credentials on other machine then new access_token is not generated and already created access_token for that account is used. This thing have some issues because if I logout from one system then it gets logged-out from other system too.
I think that creation of same access_token for same authenticated account from two different machines is not related to oAuth in any way but I' am confused why that library used such a behavior. Is this behavior default to oAuth or is it just specific to that library? I just want to make sure that if I modify that library then I' am not violating oAuth default behavior.
Any help is highly appreciated.
Thanks.
I would like to develop RESTful API for my web application. Client have to be clear JS + HTML and user have to somehow authenticate in system. I've read few articles about security and RESTful API but some point still are not clear for me. As I've understood at the first step user have to provide his credentials to server. After that server have to validate user credentials and if they are valid, sent some encoded token to user (assume it will be [user key]:[user IP]:[token creation time]). After user authentication client have to sent this this key with each API call. That's how I've understood RESTful API authentication principes.
With such solution I assume that token can be stolen and another user can access to secured user data (even if IP is included to access token and there will be validation on each request). For this purpose I plan to include token creation time but as I understand with such solution I have to renew access token each time when it expiring - in this case it's not clear for me how to implement "remember me" functionality.
It's not clear for me how to implement 100% safe authentication for my RESTful API. Maybe I'm missing something. Or maybe my understanding of authentication principes is wrong.
It depends from what authentication scenario you are using. For example when dealing with in ASP.NET MVC + REST with Basic Authentication it will produce for you token which is in the fact Base64 encoded string '{username}:{password}'. And you are right it could be stolen, that's why for Basic Auth HTTPS is must, as token goes throw Authentication header with Basic schema.
For REST security most suitable and secure are OpenId and OAuth. Just don't reinvent wheel and use already existing standards. OAuth in compare to OpenID includes not only authentication but authorization as well. OAuth already describes all nuances with token renew and token creation time and so on.
Now practical how to implement OAuth in REST. First of all read standard. For your case read with attention Implicit Grant flow, because standard has multiple flows for different client with different trust level and security.
https://www.rfc-editor.org/rfc/rfc6749
And after that you can try some already implemented library in technological stack you are using either Java or .NET. For client it is not so important to use library in compare but for server implementation
About potential security problem read here https://www.rfc-editor.org/rfc/rfc6749#section-10.
Some think that OAuth 2.0 is less secure that OAuth 1.0, and it is also dependant from token format. Anyway access token should be passed in HTTP Header and through HTTPS as well as clientid should be stored and passed securely.