ClientID and Client Secret are basically the same idea as a username and password, though keep in mind that in some contexts they could refer to different things. Either way you will generally use it to fill a basic authentication header in a HTTP request to the authorization server.
Not using a ClientID is, to my knowledge, impossible. You are claiming an identity after all, that of your OAuth client. The client has certain permissions associated with it and any long lasting grants need to be associated with a client as well.
No Secret
Not using a secret is possible, however you need to consider the following things. If you don't use any means of authentication then anyone can use your client if they know the clientID. If there is not much risk to having an unauthorized party use the client then that is fine.
Different kind of secret
Another way of not using a secret is to use other means of authentication. For example based public-private keys or certificates. The advantage here is the you are not sending your shared secret along with your request for a token, therefore your your secret cannot be intercepted. With the public-private key scenario the authorization server would send some random message to the client to have it encrypted with the private key. The authorization server can then decrypt it with the public key and validate it, or some other variation of this crypto magic. Either way the private key is not transferred and thus stays safe.
Two authorization flows
The authentication code flow will have the user (resource owner) authenticate to provide some form of access to the client. The user will be redirect to a location associated with the client, in this redirect the authorization code is passed along. The client can now obtain the authorization code and exchange it for an access token and, possibly, a refresh token. During this exchange the client will need to authenticate. In the implicit flow the user will be redirected as well, but now the tokens are passed along immediately. So there is no need for an exchange and thus no need for the client to authenticate itself.
Possible vulnerabilities
Using no authentication at all could mean an attacker will have an easy time using your client. Creating random clientIDs and creating them on the fly to destroy them once done are ways to decrease the odds of this happening. But still someone could just guess them or otherwise figure out the clientID.
Using a client secret means a shared secret between the client and the authorization server which could be intercepted. This becomes a lot harder to pull off when you use HTTPS, which you should definitely do regardless of the options you pick. Either way the possibility is still there in the case of a man in the middle attack, sniffing, weak ciphers and possibly others.
Using the implicit flow the tokens will pass through the users device where they might be intercepted and used by an attacker. Though to be honest, if this is the case the user probably has bigger problems than that.
Conclusion
OAuth gives you a lot of options and freedom to suit it to your needs. What you pick is a trade-off between ease of use and security. It depends on your use case and environment what the best option will be.
